С таким прогрессом и людей от Микрософта не надо.

И даже тысячи. Один хреновый менеджер может слить результат работы 1000 человек как делать нефиг.

грамароглистам не понять модель каверканья транслитературных слов, подчёркивающую неуважение к обсуждаемым предметам.

    Разыменовывать сырой указатель;
    Вызывать и объявлять unsafe функции;
    Читать или измененять статическую изменяемую переменную;
    Реализовывать и объявлять unsafe типаж;
    Получать доступ к полям union.

Ни о каких отключениях всех проверок Rust здесь и речи не идет. Если у вас ошибка с lifetime-ами, то просто добавление unsafe не поможет коду скомпилироваться. Внутри этого блока компилятор продолжает проверять код на соответствие системы типов, отслеживать время жизни переменных, корректность на потокобезопасность и многое-многое другое. Подробнее можно прочитать в статье You can’t "turn off the borrow checker" in Rust.

К unsafe не стоит относиться как "я делаю, что хочу". Это указание компилятору, что вы берете на себя ответственность за вполне конкретный набор инвариантов, которые компилятор самостоятельно проверить не может. Например, разыменование сырого указателя. Это мы с вами знаем, что сишный malloc возвращает NULL или указатель на аллоцированный кусок неинициализированной памяти, а компилятор Rust об этой семантике ничего не знает. Поэтому для работы с сырым указателем, который вернул, к примеру, malloc, вы должны сказать компилятору: "я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных". Вы берете на себя ответственность за этот указатель в блоке unsafe.

А кого уже заколебали эти адские переростки - есть чудный w3.css, сделаный ни много, ни мало автором w3schools. Который таки показал как делать as simple as possible, but not simpler than that. Этим гении от вебмакак и отличаются...

Вот это правильно! Давно пора!!111 Осталось добавить обвязку для выполнения в ядре printf() и abort();

Особенно по скорости компиляции, ага.
> Представляете себе лицо Линуса, когда ему дают вариант в 2.71 — 3.15 раз более оптимальный, чем он написал на Си?

В каком плане более оптимальный? Как раз таки Си - наиболее оптимальный ЯП для решения задач из области разработки системного ПО и, тем более, ядер ОС из существующих в природе. В идеале, конечно, ядро ОС должно реализовываться на более низкоуровневом ЯП'е, нежели С, но, за неимением такового, приходится использовать последний. Высокоуровневые ЯП'ы с функцией подтирания соплей за нерадивыми разрабами в этой области нафиг не сдались.

core это всеголишь набор кучки трейтов и макросов которые реализованы самим языком.

Хотите реально внешнюю библиотеку (я не про std), возьмите alloc....

Таненбаум в отличие от опеннетчиков намного более здравомыслящий тип, который даже местами признал что его взгляды тоже не вели к наилучшим результатам.

Ядерщики никогда не комплексовали по поводу выноса unsupported шмотков кода.