Около 13 уязвимостей в день и почти девять изменений в час: с такой нагрузкой мейнтейнеры ядра Linux больше не хотят тратить время на типичные ошибки C. Поэтому Rust в Linux из красивой идеи окончательно превратился в рабочую ставку на будущее. Для разработчиков, которые пишут низкоуровневый код, и для компаний, живущих на Linux-инфраструктуре, сигнал вполне прямой: правила входа в kernel-разработку меняются уже сейчас, а не когда-нибудь потом.
Об этом на Open Source Summit India 2026 в Мумбаи заявил Грег Кроа-Хартман, один из самых влиятельных людей в экосистеме Linux и сопровождающий стабильных веток ядра, сообщает ZDNet. Его формулировка звучит без двусмысленностей: ядро движется в сторону Rust, Git тоже движется в сторону Rust, и все больше крупных open source-проектов начинают делать ту же ставку. При этом речь не о крестовом походе против C. Кроа-Хартман отдельно подчеркнул: переписывать ядро целиком никто не собирается, существующий код на C останется с нами надолго. Но для части нового кода выбор языка уже перестает быть предметом вкуса.
Самый сильный аргумент у него не идеологический, а операционный. Кроа-Хартман курирует процесс, связанный с CVE в ядре Linux, и видит типовые поломки не в теории, а в ежедневной рутине. По его словам, значительная часть уязвимостей сводится к мелким, повторяющимся ошибкам на C: не туда проверили указатель, забыли освобождение ресурса, ошиблись в cleanup path, не так поработали с блокировками. Его личная, как он сам подчеркнул, нестрогая оценка такая: до 80% таких проблем Rust мог бы отсечь еще на этапе компиляции. Остальные 20% никуда не денутся, потому что логические ошибки язык не лечит. Но для команды, которая тонет в потоке ревью и исправлений, даже такой срез выглядит не косметикой, а разгрузкой производственного конвейера.
Именно поэтому Rust в Linux продвигают не как игрушку для энтузиастов, а как инструмент снижения нагрузки на ревьюеров. В ядре, по словам Кроа-Хартмана, больше 5 тыс. разработчиков, но основной массив кода проверяют примерно 150 ключевых мейнтейнеров. Баланс сил тут предсказуемо жесткий: девелоперов много, людей, которые держат качество и совместимость, мало. Отсюда и принцип, который он сформулировал почти по-менеджерски, хотя речь о ядре: оптимизировать нужно не работу автора патча, а жизнь проверяющего. Если язык и типовая система сами гарантируют корректность владения памятью, времен жизни объектов и части сценариев с блокировками, ревьюер может тратить время на логику, а не на ручную охоту за очередной банальной ошибкой, которая через месяц превратится в CVE.
На этом фоне особенно показательно, что влияние Rust уже вышло за пределы собственно Rust-кода. Чтобы безопасно строить биндинги к ядру, мейнтейнерам пришлось пересмотреть старые API на C и сделать их менее хрупкими. Кроа-Хартман прямо сказал, что многие защитные механизмы и подходы к управлению памятью появились в C-коде именно потому, что Rust заставил сообщество заново посмотреть на старые интерфейсы. И это, пожалуй, один из самых трезвых выводов из всей истории: даже там, где Rust не заменяет C, он уже меняет культуру проектирования API внутри ядра. В 2025 году Кроа-Хартман писал в Linux Kernel Mailing List примерно о том же: сложные и неудобные внутренние интерфейсы приходится чистить, потому что Rust не дает прятать их шероховатости под ковром. Для пользователей C это тоже бонус, а не угроза.
Но на одних разговорах история не закончилась. По словам мейнтейнера, для некоторых подсистем новые драйверы будут принимать только на Rust. В качестве примера он назвал графическую подсистему, где драйверы давно считаются одним из самых сложных и конфликтных участков ядра. Еще показателен Binder, межпроцессный механизм Android: сейчас в ядре существуют и C-, и Rust-реализации, но старая версия на C, по его словам, должна со временем уйти, а Rust-вариант останется базовым для Android-устройств. Это уже не абстрактный спор о красоте синтаксиса и не дискуссия в стиле «какой язык моднее». Это смена технической политики в тех местах, где цена ошибки особенно неприятна: драйверы, IPC, код с длинным хвостом поддержки и огромным парком устройств.
При этом Кроа-Хартман не изображает из себя новообращенного фанатика. Он отдельно признал, что сам много лет любил и продолжает любить C, а перемены для сообщества, выросшего на нем, даются тяжело. Тем интереснее звучит его разворот: раньше он относился к Rust скептически, теперь говорит, что этот язык снова делает программирование увлекательным, потому что убирает лишнюю когнитивную нагрузку. Для разработчика это означает меньше времени на ручной контроль ссылок и блокировок; для бизнеса, который зависит от Linux, более приземленный вывод другой: если проект ядра системно снижает класс типовых memory safety-багов, это потенциально уменьшает издержки на сопровождение, патчинг и разбор инцидентов. Не завтра, не одним релизом, но курс уже задан.
Главный вопрос теперь не в том, исчезнет ли C из ядра Linux, а в том, насколько быстро Rust станет языком по умолчанию для всего нового и чувствительного к безопасности кода. Если еще год-два назад это можно было обсуждать как эксперимент сообщества, то после заявлений Кроа-Хартмана спор выглядит закрытым: будущее ядра не будет целиком написано на Rust, но заметная часть будущего Linux почти наверняка будет строиться именно на нем. Проверить первоисточник и формулировки можно в материале .