> 1. И вот это вот вы называете не извращённым? https://github.com/Amanieu/intrusive-rs/blob/master/src/link... Хотелось бы большей конкретики. ИМХО, код как код.
> Называть безопасным язык, в котором даже простой двусвязный список
> требует unsafe реализации.
Но я ведь объяснил причину. Повторюсь. Если имеем дело с неопределённостями, причём сложными, то или обмазываемся Option, Box, Rc, Arc и т.д. (сложный синтаксис, да), либо сразу пишем unsafe. Вполне себе нормальный подход. Хотите ходить быстро (тяп-ляп, как в Си) по граблям без гарантий компилятора - ок, вот вам инструмент. Хотите гарантий компилятора при работе с динамичными и местами неопределёнными структурами - чешите репу. На Си или Плюсах, если бы вы захотели гарантий, вам бы пришлось действовать точно так же, только репу чесать ещё сильнее и дольше. Поэтому я не понимаю, чем вы недовольны.
> В ядрах операционок требуются гораздо более сложные конструкции
> с уймой перекрёстных ссылок.
Например? Кроме файловой системы в голову больше ничего особо и не приходит. Вы её имели ввиду? Или что-то ещё?
> И что, Rust мне предлагает для каждой такой структуры писать такую нахлобучку из unsafe-кода?
Ну вы же пишете подобный код на C? В котором куда больше надо делать "нахлобучек". Но к Си вы привыкли, что ли, уже просто не замечая того факта, как он морально устарел.
> И этот код нетривиальный, в нём легко накосячить и сложно косяк найти.
Гораздо проще, чем в C. Потому что куски unsafe изолированы друг от друга. Опять же странно, что вам нравится копаться в одной сплошной куче unsafe-кода, нежели в отдельных изолированных кусочках.
> И если бы мне хватало односвязных списков без циклов, я бы писал
> на чём-нибудь функциональном. Зачем вообще связываться с императивными языками, указателями
> и ссылками в таком случае?
Затем, например, что императивные языки быстрее функциональных в общем случае. Скорость решает в системном программировании.
> строгая типизация спасает от ошибок. Да нифига она не спасает, и это
> научно установленный факт.
Она не спасает от всех возможных ошибок (например, логических) - да, это научно установленный факт. Но от некоторых всё-таки спасает: например, от некорректного приведения типов. Уже жирнющий плюс.
> От ошибок спасают неизменяемые структуры данных.
С ними, понятное дело, куда проще иметь дело. Логических ошибок будет действительно гораздо меньше. Но причём здесь логические ошибки до ошибок приведения типов?
> Такое ощущение, что они вообще ни одной структуры данных сложнее массива
> в жизни не реализовывали, ни разу не программировали взаимодействующие процессы
Такое ощущение, что вы вообще не в теме, хотя утверждаете, что сыты Растом по горло. Браузер - не достаточно динамичная программа, хотите сказать?
> И что? И где? Тоже дошли примерно до уровня Redox
А что с Redox не так? Разработка затихла? Или какие конкретно претензии?
> Про Rust даже не доказана теорема о
> продвижении, которая просто must have, если вы кричите о навороченной системе
> типов.
Не в курсе об этой теореме. Гугл тоже ничего не находит. Могли бы ссылкой поделиться?
> И баги и ошибки Rust пропускает, есть много тому примеров
Ещё раз. Rust не страхует от всех возможных ошибок. Только от определённого класса: некорректное приведение типов, некорректная работа с памятью.
> только они очень сложные и нетривиальные, и рождаются в попытках реализовать
> необходимое через барьеры ограничений, которые Rust ставит.
Там, где много неопределённости - так и есть. Но в каких языках по-другому? Конкурентное программирование да ещё с динамическими общими структурами - одна из самых сложных областей в программировании. На других языках, подозреваю, то, что в Rust можно сделать хоть с какими-то гарантиями, сделать невозможно от слова "совсем". Встречалась статья, где один мужик оптимизировал софт на крупной международной бирже. За полгода ему удалось сделать то, что не удалось сделать коллективу плюсовиков за несколько лет. Главная причина - сложность многопоточного программирования в плюсах. Мужик писал на F#, где, по-видимому, с этим дела обстоят намного проще.
> Зачем в Linux-то тащить весь этот маразм?
Может потому, что это не маразм в глазах программистов Google, MS, Huawei, Amazon, Mozilla и кучи других более мелких спонсоров?
