Google будет донатить на переписывание критически важных проектов на Rust

ИМХО, у низкоуровневого C есть одно неоспоримое преимущество - крайне малый по современным меркам рантайм. Код на C отлично крутится на встраиваемых системах и микроконтроллерах. И эти встраиваемые системы всё ещё недостаточно мощные что-бы так-же эффективно крутить код на всяких java или хотя-бы питонах.

И если микроконтроллерам ничего не угрожает (т.к очень уж специфичные задачи они решают), то всяким роутерам и проектам типа OpenWRT после переезда каких-нибудь busybox’ов на раст - грядёт полная жопа как по мне.

всяким роутерам и проектам типа OpenWRT после переезда каких-нибудь busybox’ов на раст - грядёт полная жопа как по мне

С чего бы вдруг? Рантайм у раста не настолько большой, чтобы современный роутер его заметил.

современный роутер

Есть ещё актуальные производственные железки и послабее. Я вот, в совсем недавнем прошлом пускал современный openwrt (19.07) на железках с 32 метрами памяти и 4 метрами флеша. Там сложно запустить что-то кроме сишного кода со стандартной библиотекой musl. C++ и libstdc++ - уже крайне проблематично.

Есть ещё актуальные производственные железки и послабее.

Когда-то и восьмибитные железки были актуальны. Прогресс неумолим.

восьмибитные железки были актуальны

Они и сейчас актуальны ещё в виде микроконтроллеров.

Прогресс неумолим.

Ну как-бы да, но как по мне - уж лучше-бы с утечками памяти в сишном коде боролись, чем переписывать всё с нуля. Гуголь мог-бы вложиться в deepcode.ai какой-нибудь. Вот это крутой и современный подход как по мне, а не заставлять разработчиков за подачки выбрасывать в корзину кучу человеко-лет работы в «устаревших» проектах.

Ну как-бы да, но как по мне - уж лучше-бы с утечками памяти в сишном коде боролись

Это сизифов труд. Борются десятилетиями, и всё никак не заборют.

Сложность борьбы с утечками памяти преувеличена. Всё отлично ловится современным интрументарием вроде валгринда

Борются десятилетиями, и всё никак не заборют.

Смотря где и как. Думаю, что в самых основных вещах уже починили всё давным давно, по крайней мере на производстве у меня и знакомых их сишный код крутиться с аптаймами по несколько месяцев, и что-то мониторинг не показывает каких-то утечек.

Да и раст тоже не панацея, пока существуют всякие там unsafe’ы и ffi. Да и вообще говнокодить можно на любом языке. Хоть на расте хоть на яве, хоть на C# - забыл где-нибудь ссылку удалить (в C# - в event’ах, вообще, рукожопы, постоянно забывают отписываться, например), и вот тебе и утечка появится.

Утечки памяти не такая большая проблема на фоне остального говнокода, как по мне. Просто почему-то нынче модно упарываться по всяким там null-safety, утечкам, и.т.д. Недавно вот было модно упарываться по функциональщине, слава богу это прошло.

Так что сизифов труд - это борьба с говнокодом. И это никак не зависит от языка. Тут вот в соседней теме чувак страдает c alacritty написанном на расте, который судя по описанным багам работает хуже старого древнего rxvt.

Сложность борьбы с утечками памяти преувеличена. Всё отлично ловится современным интрументарием вроде валгринда

Более половины реальных уязвимостей в ПО связаны с некорректной работой с памятью: выход за границы массива, use-after-free, и далее по списку. Факт использования valgrind этому никак не мешает.

Ну вообще-то у раста нет обязательного рантайма. Т.е. когда ты компилишь его версию по умолчанию, что там да, есть небольшой рантайм, что бы отслеживать панику процессов и что-то еще. Но его вполне можно собирать и без std и этого рантайма. Эта фича специально поддерживалась с самого начала именно для встраиваемых систем. Правда я не берусь утверждать, что он удобен для разработки в этой области, т.к. никогда под встраиваемые системы не писал

Более половины реальных уязвимостей в ПО связаны с некорректной работой с памятью: выход за границы массива, use-after-free, и далее по списку. Факт использования valgrind этому никак не мешает.

всё перечисленное valgrind умеет детектировать

всё перечисленное valgrind умеет детектировать

Это совершенно не мешает появляться всё новым уязвимостям, связанным с теми дефектами, которые valgrind умеет детектировать. Не смотря на то, что софт тестируют в том числе и с valgrind.

Так получается из-за того, что ситуации, возникновение которых хакеры провоцируют в процессе атаки, при рутинном тестировании под valgrind не возникают.

В этой части Rust радикально повышает качество ПО.

Хм. Это интересно, спасибо за информацию! Как нибудь посмотрю.

https://rust-embedded.github.io/book/intro/index.html

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

Не разбираться, а сразу выступать с твёрдым заявлением, достойный пользователь ЛОРа.

Я ни с чем не выступал, а просто высказал своё мнение основанное на своём опыте, вот и все. Я лично часто вижу говнокод куда опаснее чем утечки памяти, во вполне себе прикладных языках в которых проблемы памяти вроде как решены.

Где в стартовом посте или по ссылке хоть слово об утечке?

А при чём тут стартовый пост, если я вообще-то вел беседу с другим лоровцем. Мусье не умеет в контекст ? Объясните уж тогда мне глупому, о каком именно моём заявлении идёт речь, я их вообще много делаю.

И да, безопасное управление памятью в расте оно в том числе и про утечки памяти, это чуть-ли не главное что всегда всех разработчиков под раст волнует.

И да, безопасное управление памятью в расте оно в том числе и про утечки памяти

https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html

Ну, в таком случае, раст ещё большее ненужно чем я думал.

Более половины реальных уязвимостей в ПО

А ты просто не путай уязвимости и ошибки. Тогда число проблем из-за утечек резко сокращается, раз так в 50

А при чём тут стартовый пост

При том, что он как бы задаёт тему для обсуждения. Хотите обсудить утечки – создайте другую тему. Если же вы не разделяете уязвимости и утечки, то не вводите тех, кто будет всё это читать в заблуждение. Это не одно и тоже.

И да, безопасное управление памятью в расте оно в том числе и про утечки памяти

И нет, но выше уже дали ссылку.

Более половины реальных уязвимостей в ПО

А ты просто не путай уязвимости и ошибки. Тогда число проблем из-за утечек резко сокращается, раз так в 50

И какой ты хочешь сделать из этого вывод?

Что основная проблема это логические ошибки, а уязвимости как правило в местах чтения/записи пакетов/файлов, и в расте там скорее всего будет такой же unsafe

Бензопилами продолжают резаться... Запретить бензопилы! :)