> > - Стандартная библиотека - лапша (хоть и разбита на несколько частей);
> Никто стандатрную библиотеку в ядро тянуть не собирается, не надо тут твоих влажных фантазийНу ну, alloc тянут, причём не просто, а скопировали и подправили ещё до того как изменения попадут в основную ветку раста. std не тянут ([сарказм]да как и не странно, нереально[/сарказм]), но оставшееся в виде Box есть. (Смотри исходники)
> > - скрытые паники (хороша безопасность кода: когда не попал в индекс - паникуем, и это при скольких-то там процентах проблем с переполнением буфера, которые поможет решить ржавый);
> Да уж, действиьельно, зачем паниковать при выходе за границы, лучше ж по старинке, права вовышать и творить свои темные делишки
Ну тут я смешал две претензии в одни. Черезмерное число паник в rust есть и это факт. Большинство было подано под привычным соусом прикладного софта: ну если что-то не так, то паникуем. Часть из них решена в текущей реализации Rust For Linux путём расширения alloc. И будем надеяться что в этом куске стандартной библиотеки появится опция nopanic (как минимум к этому идёт текущая работа).
Вторая претензия про то, что паника не решает вопросы переполнения буфера (которые по заверениям должен решить раст). Что делать если не кидать панику? Да ф.з., добавлять проверки на уровне компилятора? Может быть. Например, оптимизатор нормально вырезает все вызовы panic, если докажет, что они в недостижимых ветках. Но в любом случае говорить, что раст решает проблемы переполнения буфера, это чистой воды враньё.
[сарказм]Вот даже будет интересно посмотреть на реакцию Линуса, когда он увидит перехват паники в коде :)[/сарказм]
> > - конструкторы не делали (нафиг нужны), а как сделать правильно `let xs = Box::new([0u8;100500])` не знают (ну типа предлагают подправить язык и сделать `let xs = box [0u;100500]` или дать на откуп оптимизатору);
> а вот это каким боком к ядру?
А это вполне себе хороший камень в огород "системного языка программирования". Который, как какой-то питончик, не может инициализировать данные на месте без [N]RVO (ну или unsafe). А требует создания данных вначале на стеке, а потом копирует их куда надо. Но это сейчас решается в unstable rust, т.е. не готово.
> > - как быть с несколькими аллокаторами не определились;
> опять проблемы юзерспейса и каких-то суперспецефичных приложений.
На какой фиг юзерспейсу несколько аллокаторов? Он и так обойдётся. А в ядре это более актуально. Тем более там есть, например, абстракции для чистки выделенной памяти за драйверами (а контроль от утечек памяти не является сильной стороной раста).
З.Ы. Так что моё мнение: rust не готов для ядра. Что-то за год может и исправят. А что-то требует кардинальных решений по хлеще контроля времени жизни. При этом я с интересом наблюдаю что делаю в Rust For Linux. И не сомневаюсь, что плюшки раста могут перевесить его минусы (чего только стоит оператор `?`).
