чудесато в базе уязвимостей nist

У golang вообще 49, а он старше раста. При этом последней CVE-2025-22870 он не выдаёт. Так что как-то нерелевантненько вбрасываешь. Тут надо что-то посерьёзней чем по буковам искать.

UPD: Вот к примеру, по продуктам, реверс-прокси, которые часто юзаются как ingress в k8, список по популярности (личные наблюдения).

1. nginx(C): 217
2. envoy(c++) : 114
3. traefik (Go): 19

это вообще как?

Обыкновенно. Есть ада. Если бы речь шла действительно про заботу о безопасности, то писали бы на аде. А тут был разработан новый яп + из каждого утюга про него вещают. Сложи 2+2.

У golang вообще 49, а он старше раста.

голанг понадежней раста будет. там сборка мусора.

Так что как-то нерелевантненько вбрасываешь

мопед не мой. а вот -

An official website of the United States government

мопед не мой. а вот -

Не, я к тому что там надо каждую CVE-шку ковырять чтобы разобраться какой язык накосячил и как. Во многих продуктах в принципе нет пояснения на чём они написаны. Вот если взять тот-же envoy, мне долгое время казалось, что он на гошке написан, но как-то решил его поковырять на досуге - бам, а он на плюсах и нигде никаких упоминаний об этом, пока в гитхаб его не заглянешь.

Набросил так набросил. 😁

понадежней раста будет. там сборка мусора.

Как это связано, кроме тех случаев, когда утечка ведёт к крашу из-за исчерпания памяти?

Как это связано, кроме тех случаев, когда утечка ведёт к крашу из-за исчерпания памяти?

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

то, есть расхождение в 30 раз по «плотности уязвимостей». понятно, что методика подсчета неточная, но куда списать такую разницу - неясно.

верней, у меня есть разные соображения, но все они не в пользу раста.

Так он по меркам, этого самого «ойти», ещё молодой и все эти уязвимости в очень таких васепупкинских проектах из разряда «О, а я написал dns-сервер». Вот если честно навскидку не припомню такого чего-то серьёзного в бэкенде написанного на расте. Вроде бы его активно используют в гитхабе - но это всё закрытые разработки и хз насколько его там много. Да и саццесс сторей маловато (вменяемых ещё меньше).

CVE-2024-52288

libosdp is an implementation of IEC 60839-11-5 OSDP (Open Supervised Device Protocol) and provides a C library with support for C++, Rust and Python3.

Как интересно, эта уязвимость по поиску относится сразу к цпп, расту и питону. Но либа написана на си :)

Ada не даёт таких же гарантий как Rust. Их даёт SPARK, но ты затрахаешься на нём обычный софт писать.

https://ajxs.me/blog/How_Does_Adas_Memory_Safety_Compare_Against_Rust.html

Я думаю тут всё просто. Реального поля языка в базе данных этих уязвимостей нет, весь поиск по описанию. И понятно что чуть ли не в любой проект на Rust в его описание слово «Rust» включат. А когда проект на C++, то это вроде как и упоминания не заслуживает.

есть ли разумное обьяснение

Так сядь и почитай что там написано в этих репортах, половина из них это всякие cross site scripting и прочая минорщина которая внимания не заслуживает. Надо фильтровать по серьезным уязвимостям которые remote code execution дают и полный доступ к твоей системе, напимер buffer overflow.

но ты затрахаешься на нём обычный софт писать

Потому что я знаю сишку. Знание сишки мешает мне изучать аду. Когда я пытался писать простенькие программки, то у меня всегда в голове всплывали мысли вроде «на сишке бы я просто сделал так и так», так что увы.

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

Распространено заблуждение, что программисты стреляют

Разумеется, ведь программисты пишут код ;) А стреляют, например, охотники на охоте.

пишешь на Ada

думаешь: «А вот тут я на Си присунул бы сегфолт!»

Не можешь больше на Ada писать, потому что грустно.

Оооок..

это вообще как? есть ли разумное обьяснение(кроме атак корейских киберпартизан) таким вот результатам?

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

Для этого разработчики раста «творчески» адаптируют концепции успешно работающие в интерпретируемых языках, при этом оставаясь компилируемым языком.

Те они буквально ступили на terra incognita одной ногой, оттуда и повылазила куча всего. Это нормально.

Далее, на правах вещей обезьянки:

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

После чего дошкрябуют до фундамента и поймут что надо фиксить адресную математику, причём не в столько в раст, сколько в слое ниже - в LLVM (проблемы с inttoptr(ptrtoint x) => x). И в конце нас ждёт грандиозная феерия с изменением Memory model, которая повлияет на все компилируемые языки.

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

качай мастерство составления хайповых заголовков

типа

«раст победил! по количеству уязвимостей на единицу кода»

«раст уязвим? кто за это ответит?»

«надежда умирает последней - раст не торт, и никогда не будет»

«еще одна замена си сошла с дистанции - раст облажался»

удачи

Есть, но не все его поймут.

это точно

я вот , к примеру, не понимаю, зачем мне это изобретение сумрачного гения, если можно скомпилировать ту же java, или модный молодежный свежий dart?
и все будет офигеть как безопасно и гарантировано

я вот , к примеру, не понимаю, зачем мне это изобретение сумрачного гения, если можно скомпилировать ту же java, или модный молодежный свежий dart?

В Rust нет рантайма и GC, как минимум.

зачем мне это изобретение сумрачного гения, если можно скомпилировать ту же java, или модный молодежный свежий dart?

Хороший вопрос. Вам - незачем, но уже выросли поколения которым нужно упрощение разработки. В свое время так расцвела js, потом go, теперь вот пытается rust.

Школьникам скоро отменят домашние задания тк они не вывозят. Вот тогда будет весело.

нет рантайма и GC

AOT компиляция превращает ту же жабу в обычный платформозависимый бинарь, который фигачит независимо от наличия JVM в системе

но GC унутри этой неонки есть, это да
если это прям критично так что аж кушать не можешь - лехким движением руками выносишь часть логики в сишечку или в любое другое llvm компилируемое поделие
ибо!

волшебный graal и truffel интегрируют всех со всеми, без регистрации и смс

короче имеем совокупность факторов, из-за чего раст вырвался в лидеры по числу уязвимостей на килограмм кода.

1. раст слишком много высовываются (это написано на расте!), отчего немедля прилетают фиксации уязвимостей во всякие базы, и не только эту, с пометкой «срочно - руст»!

2. общая низкая квалификация растомышей. как показывает практика, под давлением хайпа, в руст идут косяком с пытонов и жаваскриптов, где представление о том, как оно внутри работает - минимально. а для «языка системного программирования» оно нужно. и это дает основной вклад в плотность уязвимостей.

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

4. ну и конечно корейские криптопартизаны, залезли в базу и подделали данные.

AOT компиляция превращает ту же жабу в обычный платформозависимый бинарь, который фигачит независимо от наличия JVM в системе

И? Рантайм-то там всё равно есть, просто он в бинарник встроен.

если это прям критично так что аж кушать не можешь - лехким движением руками выносишь часть логики в сишечку или в любое другое llvm компилируемое поделие

Да. Например, в Rust.

Например, в Rust.

пффф
и начинаешь свое творение со слова unsafe
потому что все что до unsafe ты влехкую напишешь не снимая лыж на той же java

понимаешь? вот раст и его ансейф
а вот жаба и при крайней необходимости сишечка

второе с виду поприятней первого, нет?

и начинаешь свое творение со слова unsafe

Зачем? Не начинай его с unsafe и всё будет хорошо. Ей богу, у меня ощущение, что половина ненавистников Rust тут его исключительно по мемам знает. Даже троллировать не интересно, вы же все одними и теми же мемами отвечаете.

Типа, у Rust есть реально примерно вот вагон недостатков, которые могут действительно припятствовать нормальному его применению, но ни ты, ни шизоид @alysnix про них даже близко не знаете. Грустно :(

Не начинай его с unsafe и всё будет хорошо.

смари, у меня java и я буду канпелять ее в нативный бинарь
в какой момент мне может понадобиться перейти на что-то другое? чтобы сделать что?

смари, у меня java и я буду канпелять ее в нативный бинарь

Компеляй. Кто тебе мешает-то?

в какой момент мне может понадобиться перейти на что-то другое? чтобы сделать что?

Чувак, я тебя не знаю. Я понятия не имею, в какой момент тебе может понадобиться поесть, посрать или начать писать код на Rust. Зачем ты мне такие вопросы-то задаёшь?

Зачем ты мне такие вопросы-то задаёшь?

чтобы ты подумал

по существу аппаратное обеспечение компьютера небезопасно.

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

и чем такой подход хуже чем раст, который переключается на unsafe практически по тем же причинам?

чтобы ты подумал

Мы на ЛОРе, я тут стесняюсь :(((

по существу аппаратное обеспечение компьютера небезопасно.

Чо? Ты член в куллер процессора сунул, что ли? Мой комп вполне безопасен (я только на ногу его уронил один раз).

но она не может напрямую взаимодействовать с аппаратным обеспечением

Может.

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

ЯННП. Если железо небезопасно, и для общения с ним требуется сишечка, а жаба с ним не взаимодействует, то на чём же исполняется эта жаба? На парах из отсрала и святом духе?

и чем такой подход хуже чем раст, который переключается на unsafe практически по тем же причинам?

Мне что-то кажется, ты вообще не понимаешь, что такое unsafe в Rust.

ты вообще не понимаешь, что такое unsafe в Rust.

ну и ладно, буду и дальше прозябать в неведении
картохи щас вот нажарю и будет мне хорошо

шизоид @alysnix

и тебе руста разного и побольше. и не хворать.

у Rust есть реально примерно вот вагон недостатков, которые могут действительно припятствовать нормальному его применению,

ну вот. пришел наконец специалист, и четко разьяснил отчего плотность уязвимостей в русте в 30 раз выше чем в си++.

спасибо тебе, добрый человек!

одно дело когда просто догадываешься, а другое дело - поговорить с профессионалом.

ну вот. пришел наконец специалист, и четко разьяснил отчего плотность уязвимостей в русте в 30 раз выше чем в си++.

А она в 30 раз больше? Ты загнал поиск по ключевым словам и носишься с ним. Достаточно унылый вброс, ты мог бы лучше.

у Rust есть реально примерно вот вагон недостатков, которые могут действительно припятствовать нормальному его применению

про них даже близко не знаете

Расскажите пожалуйста. Интересно.

Расскажите пожалуйста. Интересно.

однажды в черном-черном лесу, черной-черной ночью, один черный-черный программист, выстрелил себе в черную-черную ногу!

ну что, страшно дети вам уже?

Я тут давеча во время CTF одного наткнулся на парочку заданий на расте. Почему-то при одном взгляде на растовый код сразу вспомнился мем «я не трап - я программист».

Расскажите пожалуйста. Интересно.

Поехали.

Сам язык:

• Отсутствие Higher-Kinded Types. Растовики оправдываются, мол, это сложно блаблабла, но если это есть во всех языках, из которых Rust черпал идеи, включая C++, то я что-то не верю.
• Жёсткий запрет на Orphaned Instances. В Haskell это является предупреждением компилятора и этого стоит избегать, а в Rust просто запретили и всё. В результате, если у тебя trait объявлен в одном пакете, а структура или тип в другом, ты никак не можешь сделать нормально impl этого трейта без создания зависимости между двумя пакетами. Поэтому почти все крейты зависят от serde и подобных, хотя этого не слишком-то нужно.
• Просто чудовищная срань с async. Атрибут async является «заразным» для функций, т.е. если ты хочешь вызвать async функцию, весь стек вызовов до самого main включительно должен быть async. Из-за этого у некоторых библиотек есть два варианта: одна async, другая нет.
• Чудовищная срань с async #2: использование async тянет достаточно жирный рантайм и далеко не всегда ведёт к улучшению производительности. Часто наоборот, async код становится только тормознее из-за вагона блокировок под капотом.
• Срань вокруг async #3: Unpin и вот это вот всё. Просто чудовищный костыль.
• Необходимость постоянного рефакторинга, иногда в случае малейших изменений. Растокрабы любят бить себя членом в лоб, рассказывая про безопасность рефакторинга из-за мощной системы типов (всё так), но забывают сказать, что этого рефакторинга выходит больше чем в других языках. Хороший пост по теме: https://loglog.games/blog/leaving-rust-gamedev/
• Вездесущий вызов .unwrap(). Rust по идее заставляет проверять возвращаемые значения через типы Option и Result, но толпы говнокодеров просто лепят .unwrap() в код, который в случае негативного значения (None, Error, etc) тупо дёргает panic!(). Это можно было бы решить монадами, но в Rust нельзя написать нормальные монады из-за отсутствия HKT. Поэтому иногда какая-нибудь библиотечка может при несовпадении инвариантов убить твою прогу и высрать стектрейс в консоль, а тебе потом разбираться.

Тулинг:

• Rustc тормозной. Я иногда на GHC ругаюсь, но скорость сборки кода на Rust может поражать. В плохом смысле. Можешь как-нибудь на досуге собрать Firefox и оценить, сколько занимает сборка плюсовой части и сколько занимает Rust. Особенно страдает тут код с макросами (у плюсов эта проблема тоже есть, попробуй скомпилить любой код, использующий Boost::Karma/Spirit).
• Выжрать вагон памяти при сборке – ваще не вопрос.
• Гигантские бинарники. Про это уже все отписались. Если на место на диске в принципе плевать, то на скорость уже не настолько. Частью проблемы тут является пункт #2 выше про orphaned instances, из-за которых всё линкуется со всем. Проблема не распространяется на embedded и ядро, к слову. Это чисто юзерспейный задвиг.

Список далеко не полон, но это самые больные для меня вещи, пришедшие в голову с утреца пораньше. Rust получился гораздо хуже чем мог бы. Но при этом это всё равно лучше чем то что делает 95% говнокодеров на Си.

Атрибут async является «заразным» для функций

Любопытно, а есть где, что бы это было не так?

В C++ и Haskell async – просто часть библиотеки.

В расте тоже. Функция с async - это просто сахар для функций, возвращающих Future, что с ним делать - забота программиста. Реактор для асинка можно запустить и в обычной функции, например, вот так в токио: https://docs.rs/tokio/latest/tokio/runtime/struct.Runtime.html#method.block_on

вы там разберитесь для начала в вопросе, раст он язык для чего?

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

асинки - вообще бред в любом языке. применяются для публики не осилившей нормальный такой многопоток на тредах, каналах и мьютексах или стекфул корутинах(на крайняк). короче за асинки в проектах убивать надо, и это не для системного языка точно.

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

из вами желаемого очевидно следует, что вы понимаете раст как эклектическое нечто, и куда его позиционировать - еще надо найти.

короче для системщины от слишком мудрен, неочевиден по результирующему коду, избыточен.

для несистмемщины - там и так хватает яв, шарпов, голангов и скал с хаскелями, и ему там делать нечего.

В Zig вроде сначала сделали async функции colorless:

Zig infers whether a function is async, and allows async/await on non-async functions, which means that Zig libraries are agnostic of blocking vs async I/O. Zig avoids function colors.

Но в итоге нормальную реализацию async, которая бы удовлетворяла разрабов языка, они пока сделать не осилили, поэтому async в текущей версии языка не работает.

сишечка прекрасна тем, что в ней нет скрытых сущностей,

В сишечке вагон скрытых сущностей.

Функция с async - это просто сахар для функций, возвращающих Future, что с ним делать - забота программиста.

Вот именно, этот сахар – часть языка.

Реактор для асинка можно запустить и в обычной функции, например, вот так в токио: https://docs.rs/tokio/latest/tokio/runtime/struct.Runtime.html#method.block_on

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

В сишечке вагон скрытых сущностей.

вы что-ли железнодорожник? говорите конкретней.

вы что-ли железнодорожник?

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

говорите конкретней.

А чо толку? Тебе минимум в нескольких тредах уже это пытались объяснить. Как минимум, в недавнем треде про zlib. Ты всё равно не осиливаешь.

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

ну и судя по «темным и скрытым местам си», тебя еще и поезд сбил пару раз.

а судя по тому, что тебе для языка системного программирования! нужны асинки, монады и проч дрянь(вместо каналов например), ты системное программирование можешь преподавать в паровозном техникуме со всеми вытекающими.

для языка системного программирования!

Что такое «системное программирование»?

нужны асинки, монады и проч дрянь(вместо каналов например)

Для системного программирования мне они не нужны, хотя монады не помешают никогда (в плюсах они элементарно делаются вот). Я писал это в критику Rust, а не в критику Си. Ты просто читать не умеешь. Совсем тупенький шизофреник :(((

Спасибо. Интересно.

Я бы ещё добавил в недостатки так и недозревающий который год gccrs. Мне кажется, при его наличии нашлось бы больше энтузиастов попробовать rust.

Так же, мне кажется, cargo и желание по умолчанию тащить зависимости из Сети можно рассмотреть как негативный фактор.

Это тоже из раздела тулинг, похоже.