Я думаю, что консервативность кодовой базы линукса недооценена. Сомневаюсь, что в mainline возьмут.

Никто и не предполагал, что в ядре будет "обычный Раст". В Redox тоже "не обычный". И в Fuchsia.

Какой serde в ядре?..

Главной проблемой, по его мнению, является потенциальная возможность “паники ядра” в некоторых ситуациях. Это может быть нехватка памяти, когда операции динамического распределения памяти могут завершаться ошибкой. Торвальдс заявил, что такой подход в ядре принципиально недопустим.

Он говорит не о панике ядра, а о панике Раста. Это поведение функций, выделяющих память на куче в юзерспейсе, в стандартной библиотеке.

При этом довольно очевидно, что стандартная библиотека Раста в ядре и не нужна. Так было бы и с любым другим языком. В Linux не используется стандартная библиотека Си и в частности тот же самый malloc. Там свои специализированные аллокаторы.

Я знаю о нём. Он не на любой кодобазе работает. В частности, в Fuchsia код на Расте без Cargo.toml — такое cargo-geiger не умеет.

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

В отличие от Си, в Расте аудит UB требуется только в unsafe коде. Которого очень мало — в т.ч. учитывая текущую практику разработки системных компонентов или операционных систем.
Например, в сетевом стеке Fuchsia:

➜  connectivity git:(master) rg -c "unsafe" | cut -d ":" -f2 | paste -s -d+ - | bc
316
➜  connectivity git:(master) tokei
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 C                     129       119529        86791        13677        19061
 C Header              749       128257        69341        38631        20285
 C++                   860       275408       206504        24284        44620
 C++ Header              1          289          220           23           46
 Go                     69        28229        22411         2436         3382
 JSON                   85         2564         2556            0            8
 Makefile                1           23            4           17            2
 Shell                   5          188          118           38           32
 SVG                     6          131          131            0            0
 TOML                    2          100           77           11           12
-------------------------------------------------------------------------------
 Markdown              101         9067            0         7179         1888
 |- BASH                 1            6            6            0            0
 |- JSON                 3           98           98            0            0
 |- Rust                 5          211          174            9           28
 (Total)                           9382          278         7188         1916
-------------------------------------------------------------------------------
 Rust                 1029       362682       299593        22419        40670
 |- Markdown           757        20900           48        18476         2376
 (Total)                         383582       299641        40895        43046
===============================================================================
 Total                3037       926467       687746       108715       130006
===============================================================================
➜  connectivity git:(master)

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

Но это практически не важно в условиях, когда сетевая задержка доминирует над задержкой вывода на дисплей. Задержка от ввода до прихода это как минимум 2 RTT — от 20 мс до, допустим, 150 мс. На 60 Гц уже кадр выводится всего на 16,7 мс.

На мой взгляд это неадекватно. Такие разговоры допустимы на кухне в кругу друзей, а не в публичном пространстве, когда у тебя тысячи подписчиков.

Ты почитал что она твитила?

Ого, не знал такого про Эшли.

Спасибо за перевод. Одно место резануло глаз.
Я думаю, всё-таки не

"взлом без страха"

а что-то типа "колбасить без страха". Hack — быстро писать код, ломая всё вокруг.

Учитывая распределённость организации, на эти деньги можно нанимать людей по всему миру. И тогда их хватит далеко не на трёх разработчиков компаний, которые пылесосят перегретый рынок.

Реализации можно чуть больше доверять

Про какую ты реализацию в итоге?

Я считаю, для менеджера паролей критично прохождение независимоого аудита безопасности. Для официального сервера его делали дважды, а тут нет

Да, и в статье это сказано.

То, что вы разобрали — это аутентификация, а не авторизация.

Посыл у исходного вашего комментария такой, что мол это документация с сайта и она так себе как книга.
Так вот, это второе издание The Rust Book, которое написано с нуля именно как книга для изучения языка. Первое издание в печатном виде не существовало. И поэтому не стоит смешивать сайт и книгу во избежание путаницы, даже если по факту у них сейчас одинаковое содержимое.

Роман, спасибо за статью.

Написать статью для школьников, при прочих равных, потребует в разы больше времени. Почему вы требуете от автора траты этого времени, ничего не предлагая взамен — непонятно.
Тут ведь всё добровольно.

Забавно, что семантика тут такая же, как у оператора? из Rust. А тот является стабилизированной, встроенной в язык версией макроса try!(). Макрос try!() есть в Rust с 1.0 (больше 4 лет), и реализацию из пяти строк.
После этого аргументы в духе "макросы усложняют язык" выглядят смешно. Вместо написания макроса на 5 строк всей экосистемой писали if err != nil, и продолжают писать.