Дело не в синтаксисе, а в растописателях со скриптовым бэкграундом (другие на эту клюкву не клюют). Они способны испортить любой продукт. Про C++ Линус все подробно объяснил уже, та же логика и к расту применима в еще большей степени.
Писать их и сейчас уже можно. А если не говорить о готовых фреймворках, то я пытался засунуть Rust в рабочий проект в ядре еще несколько лет назад, но тогда хорошего впечатления он не оставил.
Сабж интересен больше не Rust’ом как таковым, а стабильным API для модулей ядра. В самом ядре его нет (см. Documentation/process/stable-api-nonsense.rst).
Аа, это… Не, там же no_std. Очень мало библиотек работают в таком режиме. Я думаю что для ядра будут использовать вендоринг (cargo vendor). Код нужных зависимостей герметично вкоммитят в ядро и по этому легко произвести аудит, ревью и если что, то отказать в приеме патча.
Rust они тянут ради borrow checker, а не из-за экосистемы crates. А borrow checker ничего никому не стоит
Зависимости скачиваются и их код кладется прямо в git ядра в какой-то каталог вроде third_party. Так как ядро no_std, то 99% зависимостей в этом режиме подключить будет нельзя, будут только самые простые библиотеки, обычно вытираемые в ноль компилятором. При этом tar.gz ядра как собирался без сети, так и будет собираться, потому что все включено.
Уже потом не отколупаешь раст от ядра?
Любой код, как добавили, так можно и убрать. Причем здесь Rust?