>> Например, "C++ runtime" требует библиотеку с "C runtime" и без неё не работает. Отсюда сложности с запуском Си++ в ядре. Для ядра NT мы реализовали такой "C++ runtime", который не требует библиотеку с "C runtime".
> Это нельзя комментировать --- смешались в кучу кони, люди...

Это придётся прокомментировать иначе, если вспомнить, что "C++ runtime" я скопировал из Вашего сообщения №429, где не было ничего на тему freestanding и hosted implementations или environments.

>>  К Rust-у основная претензия - «оно линкуется с libc.so, потому для ядра не годится».
> Нет. Это вы сами выдумали, и сами опровергли.

Это я читал здесь много раз, до того как кто-то показал HelloWorld на syscall и некоторое время после.

> Проблемы:
>   - cargo (который вроде как и не язык, но хрен
> от него отстроишся);
>   - единственная реализация языка, контролируемая группой попечителей с замечательной репутацией
>     (всё остальное --- недореализации, легко превращаемые в тыкву
> группой попечителей).
> Упоротый синтаксис уже так себе проблема. Есть ещё одна, но я не
> в курсе --- что там в rust'е по этому вопросу творится
> (cross, canadian).

Я могу ещё от себя добавить «в чужой монастырь со своим уставом не ходят». На том же основании не стоит тянуть Си++ в ядро, которое писали Си программисты десятилетия. Технические детали, если ими озадачиться, в конце концов решаются. Данную проблему я указал в ответ на Ваше «В чём прикол выпячивания "zero runtime" --- не понимаю». Иногда стоит освежить в памяти, что писали сами, прежде чем объяснять очевидные собеседнику вещи.

>> Представьте себе ситуацию, когда некий достаточно сложный драйвер (файловой системы) пишется и отлаживается с минимальным риском в юзерленде (через FUSE), а потом сменой ключей транслятору «портируется» в ядро. Сейчас, насколько понимаю, такой сценарий затруднён.
> Оставьте эти фантазии себе.

Я делал подобное на другом языке, потому мне не ясно, что помешало в случае с Rust - он же позиционируется как замена.