> Тут Rust не лучше и не хуже C.Си достаточно простой и потому предсказуемый. Его легко обрубить до минимально необходимого core когда никто не будет умничать в месте где это смерти подобно. Это фича.
> И в C рантайм не копеечный,
В си рантайм будет такой какой я скажу. Может быть хоть нулевого размера. Фирмвари микроконтроллеров, бутлоадеров и ядра ОС так и пишут. А фирмвари микроконтроллеров бывают очень требовательными к надежности. То что rust'o'man-ы могут лучше - делом докажите.
> и в Rust не жирный, и оба позволяют работать без рантайма.
С чем я его и поздравляю, но громкие слоганы о том что на си нельзя писать безопасно не соответствуют действительности.
> Тем не менее, количество инцидентов с оружием больше там, где к нему свободный доступ.
Почему-то статистика это не подтверждает. Недавно попадалось утверждение что крупных killing spree в США и России было одинаково за последний год. А в штатах массовые убийства обычно случаются в зонах свободных от оружия почему-то.
> Чтобы их заменить, они должны быть в достаточном количестве. Их банально не хватает.
Чудес не бывает: как заплачено так и захреначено. Предлагайте конкурентоспособные зарплаты или наслаждайтесь мартышками.
> Если есть высококлассный специалист, лучшее, что можно сделать - это
> позволить ему работать на том, на чём он хочет и знает.
А если специалист низкоквалифицированный, он будет сажать глупые баги на любом ЯП. Потому что низкоквалифицированный. Что хуже - такие кадры часто мнят себя супер-про, ворочая огромными рантаймами и фреймфорками. Получается обезьяна с гранатой.
> Та же Modula-2.
Ну и где эта Modula-2? Фирмвари на си в ответственных применениях - вижу. Modula-2 не вижу. Никак и нигде.
> Тут сама постановка вопроса удивляет, что если программист профессионал, то ему не
> нужна подстраховка. Вот Дреппер же профессионал? А сколько уязвимостей нашли в glibc?
Во первых, Дреппер далеко не единственный автор кода.
Во вторых, даже Дреппер иногда может ошибаться.
В третьих Дреппер зазнался в край, что не способствует отсутствию ошибок и работе над ними.
Но это все фигня. Основная проблема glibc - то что в погоне за фичами и производительностью glibc стал весьма жирным. А в большой программе и багов заведомо много.
> Вы назвали ужасные, с моей точки зрения, языки.
Однако в эксплуатируемых уязвимостей в самих языках не так уж много. А вот глупых логических ошибок в паршивом коде - более чем. Кто system() вызывает с пользовательскими данными, кто файлы пишет черти-как, не зная что пользователь может воткнуть в имя файла что угодно, даже "../../etc/passwd". Некоторые переклинены на текст-ориентированных ЯП, поэтому подолбать их неправильным эскейпингом и далее всучить им странную строку делающую совсем не то что они думали - милое дело. А вон DHCP сервера красиво рутали linux за счет isc dhcp клиента в паре с bash.
> Точнее, как скриптовые они может быть и неплохи, то есть для такого кода, который не
> надо никому показывать, но для построения крупных проектов динамическая типизация - это болото.
Это реально минное поле. Можно спокойно приравнять бананы к гвоздям, никто ничего не скажет. JS из той же области. Очень бесит. Си в этом плане близок к оптимуму. По дефолту обругает но если я очень хочу считать бананы гвоздями - можно заэнфорсить явно. Те кто так делает должны разумеется понимать - нафига. Паскаль какой-нибудь в этом плане сильно противнее - убедить его что бананы это гвозди можно только при помощи трехэтажных костылищ. В конце концов бананы все-равно пойдут под видом гвоздей, если уж это надо, но долбаться придется больше и ЯП начинает активно мешаться.
> Поэтому в ФСБуке и делают свой транслятор для PHP-образноко языка со статической типизацией.
У них еще и субсет урезанный и даже предкомпилируемый IIRC. Они пилят большой проект и огребают сполна все прелести. И по части производительности и по возможности это поддерживать.
Но на си написаны монстрики типа линуксного ядра. Там кода побольше чем в любом фэусбуке. А оно еще и как-то работает.
> Лучше языка Ada, массово применяемого в авиастроении? Очень критичная область, надо сказать.
Сказать что Ada массово применяется - покривить душой. А так то NASA делало еще более забористый язык, где описываются допустимые переходы между состояниями объектов. И все это круто и замечательно, только у NASA релизы редкие, финансирование условно-анлимное, задача более-менее ясна сразу на старте. Поэтому они могут попыхтеть и нормально притянуть архитектуру к формальному описанию.
А какой-нибудь Элон Маск - юзает обычный Linux и даже компоненты не rad-hard. А надежноть добивает многократным резервированием, т.к. это ширпотреб - можно поставить много и выехать на этом. И ничего, летает. Что у него только не фэйлило, но это в основном механика и просто не отлаженные экспериментальные технологии. А бортовые компьютеры по крупному вроде ни разу не отказывали.
> Тут, как раз, архитектура и язык могут решать.
А могут и не решать. А иногда можно сделать ход конем и из кучи ненадежных систем можно сделать надежную мета-систему. Просто крутанув теорвер в свою пользу. Этим развлекаются и Маск, и Гугл и кто там еще. Основной плюс - это дешево и использует уже готовые решения, не требуя сверх-затратных вещей. Которые может и круто и здорово, но даже NASA напрягается и могло позволить себе такой шик только к лунной гонке, когда их финансировали анлимно.
> QNX характерна устойчивостью к падению за счёт микроядерной архитектуры.
И все бы замечательно, но у меня и прозаичный Linux не падает. Год аптайма в эмбедовке он точно делает. Больше - иногда таки софт обновляют. Или просто пропадает питание. Ну и что там даст переписывание на микроядра, даже на аде? Много гемора с результатом близким к нулю?
> с герметичными типами была устойчива, хотя при желании и можно было
> запороть память псевдомодулем SYSTEM.
А сейчас, понимаешь ли, периферия - это участок памяти. Потому что это круто, просто, быстро и можно разгрузить DMA. Кстати одно неверное программирование DMA - и железка прострелит череп системе. Софт это даже перехватить никак не может. Железо научилось перехватывать это относительно недавно (iommu). Вообще, современное железо настолько сложное и хрупкое что все эти извраты с супернадежностью на нем себя не оправдают. Супер-ЯП может посыпаться на какой-нибудь errata железа. А линуксное ядро с его сями эту errata три раза прокостылило, собрало feedback и проверило фикс годами работы без сбоев. Так и живем. Железо сейчас ни разу не лучше софта.
> Речь идёт лишь о том, чтобы исключить проблемы, решаемые языком.
Звучит как план по отливке серебряных пуль. В том плане что упомянутый язык создает не так уж много проблем и они достаточно известные а профит в лучшем случае весьма маргинальный. А сватаемая муета к тому же не совместима с существующим софтом (простите, а на rust можно написать либу? А чтобы потом еще и прикрутить ее к другим ЯПам, как сишную? А сишную либу к rust?). Там вроде с этим тот еще факап. А планы резко переписать все на Rust - форменное донкихотство. Извини, с 1989 года на том же си понаписали много чего и отказываться от этого никто не будет. Желающие могут переписать на этом хотя-бы Linux или как там это будет называться для начала. Для понимания масштаба работ, если на совместимость таки будет решено положить.
> пуле никто не мечтает, но упрощение жизни - возможно. Не нужно кидаться крайностями,
Чтобы не кидаться в крайности должен быть нормальный интероп с существующим софтом. Rust в этом чем таким вообще похвастает?
