>Низкопрофессональное ядро сообщества и отсутствие продуманного последовательного дизайна приводит к невозможности интуитивного качественного программированияТак можно про любой проект сказать в котором выявили уязвимость. Вот только доказать трудно.
>что выливается в патчи с пачками unsafe
Это стандартная либа, там низкоуровневый код который без ансейфов не напишешь. В этом и суть стандартной либы - собрать часто используемые/опасные примитивы. При этом написать максимально скоростной код.
>что почти гарантированно приведет к нарушению безопасТности работы с памятью.
(Безотносительно того что новость про логическую ошибку, от которой не защитит ни один язык или компилятор.) При выявлении нарушения безопасности работы с памятью (SEGFAULT) возможные места ошибки локализовать проще если знаешь места где она может быть нарушена (UNSAFE-блоки). Также наличие unsafe-блоков позволяет проще провести АУДИТ кода! Профит.
>В так сильно критикуемом растаманами С++ совершенно точно такая же безопасность работы с памятью обеспечивается с помощью использования умных указателей
Google Chrome написан на С++, а в нем 75% уязвимостей это уязвимости работы с памятью.
Код Microsoft страдает от той же проблемы. Хоть там и не раскрывают долю кода на Си. Там тоже 75%.
Я уже не говорю про множество необычных проблем подобных https://www.amse.ru/courses/cpp1/2010.04.07.html
или таких https://habr.com/ru/post/114117/ которые safe-раст успешно обходит.
>При этом С++ не страдает от такого зоопарка различных специальных символов в языке, дичайшего многословия
(Безотносительно легаси подмножества https://godbolt.org/z/hzWbGjG4j ) Все-таки чтобы получить выхлоп ассемблера соответствующей Растовому придется попотеть https://youtu.be/rHIkrotSwcc?t=1189 Когда в Расте это все дефолты.
Вот этот пример из видео https://rust.godbolt.org/z/Ed69aKqah (unsafe здесь для FFI, чтобы компилятор не соптимизировал наши функции до нуля. В реале его не будет.)
