«Зелене світло» для Rust: Лінус Торвальдс підтримуює інтеграцію в ядро
Час невпинно спливає, але суперечки навколо інтеграції Rust у ядро Linux не вщухають. Лінус Торвальдс у приватній розмові з Крістофом Хелвігом чітко дав зрозуміти: він підтримує використання Rust, навіть якщо це викликає опір частини мейнтейнерів. На його думку, майбутнє Linux залежить від впровадження нових технологій.
Грег Кроа-Хартман також виступає за інтеграцію Rust, наголошуючи, що ця мова здатна вирішити низку проблем, притаманних C. За його словами, більшість багів спричинені нюансами C, які Rust просто усуває: переповнення буферів, використання пам’яті після звільнення, забуті перевірки помилок тощо.
«Більшість багів (за кількістю, а не за критичністю чи серйозністю) виникають через дрібні корнер кейси в C, які повністю зникають у Rust. Це такі речі, як прості перезаписи пам’яті (не те щоб Rust міг виловити всі з них), очищення помилкових шляхів, забуті перевірки значень помилок, помилки use-after-free тощо. Ось чому я хочу бачити Rust у ядрі: ці проблеми просто зникають, що дозволяє розробникам і мейнтейнерам зосередитися на СПРАВЖНІХ багах (логічних помилках, умовах гонок тощо).»
Окрім підвищення надійності, Rust допоможе структурувати внутрішній API ядра, спростивши життя мейнтейнерам та навіть тим, хто продовжить писати на C. Щодо поєднання мов, Кроа-Хартман не бачить у цьому загрози: Linux уже проходив через більші виклики, і немає причин відкидати ідеї, що визначатимуть його майбутнє.
Колишній головний адміністратор kernel.org та лідер Ubuntu Security Team Кейс Кук також підтримує ініціативу. Він уточнює, що Rust не використовуватимуть для переписування старого коду, а лише для створення нових драйверів і підсистем. Це не лише мінімізує помилки роботи з пам’яттю, а й пришвидшить розробку: завдяки строгим гарантіям Rust помилки виявляються ще на етапі написання коду, задовго до тестування.
«Мета? Викорінити проблеми з безпекою пам’яті в новому коді, — каже Кук. — Дослідження Android та Usenix довели, що такий підхід має експоненційний ефект: кількість вразливостей значно зменшується».
Схоже на те, що ключові фігури Linux-спільноти вже дали Rust «зелене світло». Тепер питання не в тому, чи з’явиться він у ядрі, а коли саме це станеться.
Читайте також: «Не змушуйте нас працювати з вашою модною мовою!» або чому Linux-розробники воюють проти Rust, Конфлікт в Linux продовжується: Крістоф Хелвіг залишає посаду мейнтейнера
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівRust часто асоціюється з криптовалютами, блокчейном та Web3, а серед таких проєктів багато шахрайства.
І після цієї публікації на DOU хтось, можливо, захоче перекваліфікуватися на Rust.
Раніше я писав, що формую список компаній, де використовується Go. У цьому списку тільки продуктові компанії та стартапи — без аутсорсерів, без агенцій, без криптовалют і без азартних ігор.
Але разом із Go-списком я також формую список компаній, де використовується Rust.
Ви хочете скомпроментувати rust (для чого?), чи деякі проекти на блокчейні? Ваша заява це певна форма маніпуляції. Для чого вимащувати мову програмування в певних проектах. За такої логіки будь яку (!!!) мову можна прив’язати до проектів повязаних з шахрайством!
Якщо в моєму попередньому коментарі залишити тільки перше речення, яке ви й змогли осилити, тоді ваш коментар стане доречним
Пишу окремим коментарем, щоб ви змогли осилити: я формую список компаній із Rust, де відсутні проєкти, пов’язані з криптовалютами, блокчейном, Web3, NoCode, LowCode та азартними іграми, зокрема новомодним iGaming
Разве что у людей, которые работают в сфере криптовалют, блокчейна и Web3
make C greate again.
наприклад, доробити пайплайн C щоб він відсіюював більшість помилок
Rust активно просуває Пентагон. В цілому же недоліків в нього не менше ніж переваг. Я поважаю Лінуса Торвальдса, та в цьому його конкретно рішенні — повністю не згоден, гімнокод на Rust так само гімнокод як і гімнокод на будь чому. Те що там на комітили — відверте наскоро зроблене лайно, але на Rust.
Самому же проекту Linux не вистачає модульної структури сбірки пакетного менеджера, що в Rust — це Cargo, санітайзерів — що частково вбудовані в сам компілятор Rust (тим не менше далеко від сучасних типу Сpp Check із вільних) і т.д. осучаснення розробки.
Щоби скористатись перевагами які надає інфраструктура і можливості Rust, на нього треба портувати усе ядро і не по троху, так не працює або одразу усе або нічого (перевірено реальним досвідом роботи, як тільки проект реплатформлять «по троху» з того не виходить нічого путнього).
Скажімо реально вдача із портуванням — це проект Botan. А от FireFox — еталонний Rust проект чомусь так стається, що проміжні релізи бувають сильно з багами. Хоча так перші версії — були значно краще ніж на застарілому С++ (навіть не С++ 98). Chrome на модерновому С++ навпаки перші версії були такі собі, зараз навпаки стабільний.
У файрфокса не також вже й багато rust якщо розбивку по мовам глянути, с-плюсів явно більше, чому не переписують на rust решту — хз, мабуть щось заважає.
p.s. Лінус якби вважав що тулза для збирання не задовольняє потреби, то думаю прикрутив би щось типу meson, чи своє написав би. Якщо не міняє, значить вважає того що є того достатньо.
Хм а дійсно (доволі давно вже не працюю з кодовою базою позаяк змінив місце робти) Так там навіть доля Kotlin в репозіторії движка, більша за Rust. Оcкільки вони в 2023 перейшли на Git та Github з Mercurial, то Github усе підрахував.
github.com/mozilla/gecko-dev
Більше за усе в FireFox коду історично з версії 3.0 на JavaScript 28.1% (майже весь UI через XUL Framework), що і не дивно сама мова розроблена в рамках проекту тоді ще Netscape Navigator. Далі С++ 28.3%, С — 10.8%, Python 2.9%, Kotlin 2.4% а Rust потрапив в маргинальний список 5.5% — інше.
Тобто Rust в FireFox — це чистої води маркетинг. Напевно має місце якась программа з просування технології типу : Algol 68, Ada і т.п. через FOS. Та треба визнати в усі минулі рази Пентагон та Карнегі-Меллон із цим провалився. Індустрія усеодно вибрала не канонічні С та Unix від Bell labs AT&T, а не те що просував Пентагон із намаганням «зробити по уму». Підозрюю оці просування зараз будуть різати як USAID.
Станом на сьогодні пальма ідустріального ледерства від Bell Labs (AT&T) перейшла до Google. І тут вже в очевидь якщо Google массово піде в Rust — то за ним і усі. Станом на зараз він більше йде в модернізацію С та С++ активно працює і впливає на комітет, а також поглинув до себе співробітників самого Bell Labs. Через суди із Oracle за Java — пішов в діалект Java, Kotlin — доля якого реально постійно росте, зокрема через Android. Мова так само має свої певрні переваги над модерновою Java (від старої Java 1.6 коли мова тільки виийшла переваги були дуже значними, зараз це вже не так Java 21+ подекуди краща і взяла багато чого в самого Kotlin) і низку своїх недоліків.
Так само росте доля Go Lang — реально, бо Google. Хоча як порівнювати Rust то Go lang — то у Rust безперечні переваги. Але Go lang — технологія Google.
тоді напевно то був фортран для заміни на ada (ще застав фортран, але вже не побачив те що йому просували на заміну перед цим), а заміну для С передбачали набагато пізніш — Java — «немає сенсу вчити інші мови, бо завтра всі будуть писати на safe java» було. Не витіснили, але свою нішу точно зайняли, можливо так само і з rust буде.
p.s. go суттєво відрізняється від rust використанням зараз (бекенди і т.п.) і його не просувають так настирно, тобто він свою нішу вже певно знайшов і добре себе почуває
Якщо брати безпечність розробки, то так. Але якщо брати швидкість, час, який потрібен на опанування мови, ... Тут скоріше ілюстрація, що великого попиту на безпечність немає.
Так і go наряду з rust в певному сенсі safe (як і багато інших), єдине що під safety кожен вибирає свої аспекти щоб заапрувити точку зору. Напевно з часів паскалю всі нові мови вже були safe в свому розумінні.
Та тут інша справа. Оскільки треба взаємодія із кодом на С, то на відміну від : С++, Objective C або Zig, треба робити купу от таких врапеерів як для Rust так і для Go lang. Так само як скажімо для Python чи JavaScript або Java чи C#, у яких насправді є ціла масса інших дуже суттєвих преваг. Крім того, банально як тільки є взаємодія із С — більше нема ніяких «переваг мови». Відповідно чи фінансво вигідною є дуже суттєве збільшення трудоміскості робіт і чи виправдовує воно пререаги ???
Та як бачимо такі проект як Docker та Kubenetes написали цілком на Go lang. Тобто певний запит усе таки є. А сьогодня вже beacked без обох технологій уявити складно, це загально розповсюджено і must have знання. Хоча окремі проекти активно портоують критичні компонентия як то crun на С з Go lang і мають дуже великі переваги по швидкості і пам’яті одночасно тільки за рахунок іншої «менеше безпечної мови», бо С інтрумент тонкий як лезо бритви який доволляє створити як шедевр так і криваве місиво. github.com/containers/crun А от Go lang — або в меншій ступіні Rust, це плата за абстаракціі.
Буде як з IPv6, внести-то внесуть, але взлітати не захоче за межами нішевих підсистем.
Ответ Торвальдса по поводу блокировки Rust враперов к DMA подсистеме: https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/
Ну схоже тре вчити rust як би я його ненавидів.
Мова програмування то тулза під задачу, тобто щось вчити аби вчити так собі ідея. Хоча з іншого боку періодично продивлятись що в інших мовах є — то певно корисно, але з цієї точки зору раст цікавий був років5-10 назад, чи коли пік хайпа з рік два тому, а зараз крім промошена мабуть нічого нового.