Почему? Пока не сталкивался с таким мнением, так что интересно.
Могу привести пример:
Си со своим беззнаковым sizeof провоцирует использование беззнаковых целых, повышая вероятность переполнения из-за близости нижней границы, которое даже не может вызвать прерывания, так как в стандарте чётко прописано "корректное" поведение. Для Ржавого всё лучше в это плане, и не только. Впрочем, я не имел возможности его использовать широко, могу чего не знать.
Ну, моё мнение довольно скучное тут и занудное: всё просто, у Rust сырой компилятор, сырой рантайм, сырые либы и полное отсутствие инструментария для анализа кода.
В системах где актуальна MISRA там голым компилятором (пусть и полностью соответствующим стандарту) никто не ограничивается. Для любого языка. Вокруг этого строится целая система по повышению надежности кода. Делается специальный инструментарий для анализа кода, по верификации кода и так далее. Для той же Ады специально для нужд построения таких тулзовин был изобретен ASIS (
https://en.wikipedia.org/wiki/Ada_Semantic_Interface_Specification ). Всё это делается не один год и не один десяток лет, всё это потом еще и сертифицируется. И нарабатываются методологии как этим всем пользоваться, как обучать людей и так далее.
Далее - например даже в фитнес-приложениях по хорошему нельзя использовать стоковый GCC. Собственно на нем даже написано: "There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." Компилятор должен пройти сертификацию. Поэтому, кстати, даже писатели на Си и С++ как только им действительно нужна надежность, ибо мишн критикал система, они таки покупают у AdaCore ихний GNAT (да, туда входит и C/C++ компилятор на базе того же GCC, только вот он уже верифицирован, сертифицирован и есть гарантии надежности кодогенерации).
У Rust ничего подобного даже близко нет.
Но зато в приложениях уровня "фигак и в продакшн" (то есть задачи не мишн критикал, а наоборот - фиче хангри), на нем будут да, более надежные приложения получаться - просто потому, что никто там дополнительными инструментами не заморачивается, работают с голым компилятором (ну, плюс средой разработки), методологии уменьшающие число ошибок не используются (а используются наоборот - методологии позволяющие быстрее выкатить релиз удовлетворяющий фичереквесты пользователя), и число ошибок сажаемые прикладным программистом в ходе решения задачи тут много больше числа ошибок из за багов в компиляторе, кодогенераторе и рантайме языка. И вот тут язык имеет первоочередное значение.
Ну а в мишн критикал системах выбор именно языка вносит не самый большой вклад в надежность всей системы, намного важнее процессы, методологии и инструментарий вокруг, коллектив (в том числе доступность специалистов - если у вас 100 специалистов желающих писать на языке X и 1000000 специалистов желающих писать на языке Y, то при прочих равных для языка Y вы (если не поскупитесь) сможете набрать 10 специалистов более высокого уровня чем для языка X - кстати, то же работает и в плане бенчмарков ЯП. Чем больше программистов, тем больше шанс что хоть кто-то сможет запостить решение которое будет работать реально быстро. Естественный отбор.). В конце концов марсоходы запрограммированы на С++, и отлично бегают. Мишн критикал как он есть.