Компания Amazon и организация Rust Foundation представили инициативу, нацеленную на повышение безопасности стандартной библиотеки языка Rust. Целью заявлена проверка надёжности и безопасности функций, в которых используется ключевое слово "unsafe", допускающее операции, небезопасно работающие с памятью, такие как разыменование указателей, изменение статических переменных и обращение к внешним библиотекам на С/C++. Отмечается, что в настоящее время стандартная библиотека Rust насчитывает около 35 тысяч функций, из которых в 7500 встречаются блоки кода, выполняемые в контексте "unsafe". За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62286
> При этом за последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости.Как же так? Ведь Rust должен был обернуть небезопасные части в загончик unsafe, чтобы как раз не было такого.
Выходит, не помогло? А верифицировать любой код можно, не только Rust.
> Ведь Rust должен был обернуть небезопасные части в загончик unsafe, чтобы как раз не было такого.Так они это и сделали. Поэтому проблемы если возникают, то именно unsafe блоках.
Не считая логических багов. От них только формальная верификация и спасет.> Выходит, не помогло?
Наоборот, помогло. Посмотри сколько функций и в скольки есть unsafe.
> А верифицировать любой код можно, не только Rust.
Можно. Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках.
А это почти в 5 раз меньше работы.
>А это почти в 5 раз меньше работы.А вот это вряд ли, потому что каждое включение unsafe на Rust в 5 раз сложнее проверять, чем в других языках.
>каждое включение unsafe на Rust в 5 раз сложнее проверять, чем в других языкахКак вычислялась эта метрика?
> Как вычислялась эта метрика?Методика 'Пальцем в небо' сертифицированного сотрудника 'НИИ Кекспертизы и вбросов' им. Опеннета.
Все утверждения истинны на 146%!Я бы спросил в чем отличие unsafe rust от обычной сишки, но смысла нет - все равно ответа не получим))
В чем отличие safe rust от обычной сишки?
Больше лишних проверок, которые в си пришлось бы писать руками на каждый чих.
Гм. Странное у вас определение понятия "лишний". Вот Гугл, Майкрософт и прочие компании, применяющие Rust, считают, что эти проверки совсем не лишние. А эксперт с Опеннета - что лишние. Кому верить?
Как я понял, даже unsafe в rust более безопасен, чем Си.
Потому что в rust даже в блоке unsafe производятся некоторые проверки
Нет. Ровно наоборот.Даже если иметь кривые руки, плохую голову и что-то натянуть против раста, то верификация unsafe в его собственных библиотеках потребует в разы меньше усилий чем верификация сишных библиотек со сравнимым функционалом.
В среднем по больнице, unsafe-код в Rust более регулярен и проще (менее комплексный) чем подобный в сишных библиотеках.
Есть и обратный эффект, в unsafe-функциях концентрация странностей/мутностей больше чем в средней glibc. Но это только потому, что в rust есть возможность и стремление отделять мух от котлет, а в glibc любые unsafe операции могут быть в любом месте (в самом безобидном и неожиданном).
Конечно, можно найти зубодробительные unsafe-сценарии, но тогда и сравнивать их надо с аналогичными сишными случаями.
Язык си необоснованно сложнее и найти там что-то ещё сложнее вывод очевиден. Хотя вывод понятен по отсутствию софта написанного на раст. Особенно в областях где хваленая работа с памятью могла бы иметь место.
> Язык си необоснованно сложнее и найти там что-то ещё сложнее вывод очевиден.Язык Си сильно проще, а С++ отягощен поддержкой обратной совместимости (с позволением всего unsafe что можно в Cи).
> Хотя вывод понятен по отсутствию софта написанного на раст. Особенно в
> областях где хваленая работа с памятью могла бы иметь место.Так ведь именно активно используется, даже не взирая не упомянутые выше баги.
И переписывается на Rust достаточном много, там где либо высоки риски и в совокупности есть целесообразность для бизнеса, либо где что-то кому-то интересно.Другое дело, что в условном debian этого не видно, ибо 90% пакетов появились до раста и вся экосистема "сишная".
Может уже пора перестать переписывать и написать что-то новое на самом расте?
Лол. Кто ты вообще такой чтобы что-то, кому-то указывать? Особенно разрабам которые свои проекты на Rust перекатывают.Да и нового софта на Rust уже вагон, и игровые движки и редакторы кода, и целая DE с прикладнухой. С разморозкой!
There 5 games and 50 game engines written in Rust, как говорится.
Такое всегда бывает. Сначала вызревает какой-то движок (несколько движков). Потом появляются игры на них. На Плюсах только потому больше игр, что он намного старше Rust. То же можно сказать и про другие языки, на которых обычно пишут игры.
> На Плюсах только потому больше игр, что он намного старше Rust.Ты явный оптимист и не знаешь что такое разработка игр.
На rust могут начать разрабатывать игры, только потому, что разработчики на rust валяются под каждым углом и стоят копейки.
Ну и хобби проекты.
так так и делают. просто нового кода всегда меньше чем уже написанного
unsafe это только индикативность для менеджеров или реализует безопасные механизмы (замыкание, контекст, виртуальность)?
> Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках.в другом языке есть формально верифицированный компилятор
а у раста пока что даже не формализовали ситему типов
https://blog.rust-lang.org/2023/01/20/types-announcement.html
> в другом языке есть формально верифицированный компилятор
> https://compcert.orgНисколько не хочу принизить ценность проекта и достигнутые там результаты, но всё-таки нужно слегка критично читать написанное с осознанием всего комплекса проблем/задач.
Формальная/математическая верификация покрывает часть функционала, т.е. "не всё".
При этом возникает некая проблема/задача верификации "самого верификатора", т.е. доказательства что сформированного списка свойств достаточно для "верифицированного компилятора".Например, предположим что у вас есть "верифицированный компилятор". В нём могут быть баги ?
- если "нет, багов быть не может", то упомянутый компилятор нельзя назвать верифицированным.
- если "да, баги могут быть", то верификация перестаёт что-либо гарантировать на практике.Поэтому все подобные верификации всегда с массой уточнений и оговорок "тут рыбу заворачивали, сюда не смотрим" и "если остальное работает верно".
Соответственно, отсутствие "формализированной системы типов" им не только не мешает, но и может помогать (сокращать поверхность).
> Поэтому все подобные верификации всегда с массой уточнений и оговороктам написано вполне ясно
> Such verified compilers come with a mathematical, machine-checked proof that the generated executable code behaves exactly as prescribed by the semantics of the source program.
> Соответственно, отсутствие "формализированной системы типов" им не только не мешает, но и может помогать (сокращать поверхность).без формального описания не может быть никакой верификации, как это может "помогать" ?
> без формального описания не может быть никакой верификацииэто называется спецификация, в этой же спеке определяется понятие "баг".
> это называется спецификация, в этой же спеке определяется понятие "баг"есть один компилятор и никто точно не знает как он работает, только догадываются. Сомневаюсь что кто-то в своём уме пишет на этом доверенный код.
> есть один компилятор и никто точно не знает как он работает, только догадываются.На то и спека, где это все описано, и есть механизм верификации и валидации, который позволяет проверить с тем, что написано в спеке.
> Сомневаюсь что кто-то в своём уме пишет на этом доверенный код.
У кода, формально верифицируют его корректность. Вы понимаете, что такое корректность?
> У кода, формально верифицируют его корректность. Вы понимаете, что такое корректность?есть код на языке программирования и есть код исполняемый процессором, вы разницу вообще понимаете ?
> есть код на языке программирования и есть код исполняемый процессором, вы разницу вообще понимаете ?а какая разница, если и то и другое надо верифицировать? Цель верификации одна -
"""
формальное доказательство соответствия или несоответствия предмета верификации его формальному описанию.Предметом выступают алгоритмы, программы и другие доказательства.
"""
>> без формального описания не может быть никакой верификации
> это называется спецификация, в этой же спеке определяется понятие "баг".Не важно как называется, но суть в определении рамок/границ что верифицируется, а что оставляется за скобками.
И тут всё правильно, ибо по-другому не возможно.
Но нужно понимать что именно верифицировано и в "каких терминах", так как в конечном счете нет большой разницы чем будет вызвана проблема -- багом компилятора, не-верифицированностью каких-то его частей, либо изъяном в правилах/целях/критериях/ограничениях верификации.
Поэтому читая "верифицированный компилятор" всегда хочется понять что имели в виду:
- конкретный exe-шник.
- набор исходников или какое-то их подмножество.
- представление кода и его преобразования описанные в некой формальной системе, для которых доказана их корректность.
- формальная система для описания представления кода и его преобразований, которая позволяет выполнить доказательства корректности.
> Не важно как называется, но суть в определении рамок/границ что верифицируется, а что оставляется за скобками.Ну и как продолжать дискуссию, если нет понимания для чего вообще нужно это все, если изначально не важно как это все называть.
> Поэтому читая "верифицированный компилятор" всегда хочется понять что имели в виду:
Читая где? вот откройте страницу этого компилятора и прочитайте, что там специфицировали, что верифицировали и валидировали, и как это все вам повторить в домашних условиях. Хотя сначала нужно открыть и прочесть теорию данной области (формальной верификации). И все вопросы вида "что имели в виду" сразу отпадут.
> багом компилятора
Ну дайте мне строгое определение этого термина. Правильно ведь, без толку его мне щас давать?
вера+фикция = верификация.. на том и держится
> без формального описания не может быть никакой верификации, как это может "помогать"
> ?Ту там же символьные вычисления и местами абстрактная алгебра.
Например, можно верифицировать что "компилятор" не нарушает систему типов, без полной формализации и/или верификации самой системы типов.
Конечно, такой "компилятор" может быть не в состоянии генерировать исполнимый код.
Либо всё-таки уметь это, но уже с подмешиванием не-верифицированного функционала и/или не-верифицированной системы типов.А еще может выясниться, что конкретная система типов может не-покрываться/требовать-большего, чем умеет верифицированная часть компилятора, и/или требовать снятия части ограничений/формулировок введенных для возможности верификации, и т.п.
--
Собственно, хотел обратить внимание, что есть "рамки верификации" и почти всегда практическое применение никак в них не помещается.
> Собственно, хотел обратить внимание, что есть "рамки верификации" и почти всегда практическое применение никак в них не помещается.что такое "практическое применение"? Что такое "рамки верификации" когда есть строгое определение "предмета верификации"?
в расте есть MIRI
>в другом языке есть формально верифицированный компилятор
>https://compcert.orgТипичный опеннет. Неужели вам не понятна разница межу "компилятор верифицирован" и "вот эта вот библиотека верифицирована"? Компилятор верифицировать - ерунда, а вот перелопатить тонны библиотек - та ещё задача.
> Поэтому проблемы если возникают, то именно unsafe блоках.https://github.com/Speykious/cve-rs - в фантазиях.
> А это почти в 5 раз меньше работы.
Нет, это столько же работы, точнее даже больше. Сейф раст ничего не гарантирует.
Вот эпичный тред, где люди в течение недели(!) пытались заставить это работать
https://github.com/Speykious/cve-rs/issues/4Им пришлось написать самописный null_mute, модифицировать transmute() подменив там crate::null_mut на самописный... и даже после этого получается ошибка компиляции
error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
error: could not compile `cve-rs` (lib) due to previous error
Не знаю, что ты там компилируешь?
$ cargo install cve-rs
$ ~/.cargo/bin/cve-rs segfault
Segmentation fault (core dumped)
> Нет, это столько же работы, точнее даже больше. Сейф раст ничего не
> гарантирует.Но только в фантазиях опеннетных кекспертов-военов супротив раста, не ходящих по своим же ссылкам.
https://docs.rs/cve-rs/latest/cve_rs/lifetime_expansion/inde...
> How it works
> There is a soundness hole in the Rust compiler that allows our domain expansion to work....
> rustc should infer that one of the lifetimes does not outlive 'static, so that we can’t
> use lifetime_translator; however, for whatever reason, it doesn’t, so this exploit works.
> See https://github.com/rust-lang/rust/issues/25860 for this bug’s bug report.Воены-кексперты, что с лицом?
>> https://github.com/rust-lang/rust/issues/25860opened on May 28, 2015
>Воены-кексперты, что с лицом?
У меня всё прекрасно, а у вас что с лицом уже почти 10 лет?
> Сейф раст ничего не гарантирует....
> opened on May 28, 2015
>>Воены-кексперты, что с лицом?
> У меня всё прекрасно, а у вас что с лицом уже почтиКакое ловкое переобувание в прыжке, однако ...
А ты забавный. Тебе показывают, что язык дырявый. Ты даешь ссылку, что дыра существует 10 лет. Причем в обсуждении дыры прямо пишут, что у раста проблемы тайпчекером и системой типов. 10 лет.
Не язык, а компилятор. Да, нашли в нём недоработку. И?
> Не язык, а компилятор.На данном этапе развития rust язык и референсный компилятор неотделимы. И повторюсь, пишут что есть проблемы с системой типов - это именно про язык. Исправят только в "следующем поколоении".
Даже на данном этапе язык и компилятор - это разные вещи. Поскольку одно есть, условно говоря, спецификация (набор RFC в случае Rust), а другое - её имплементация.Про систему типов хотелось бы больше подробностей.
Про систему типов вы вот эту ссылку имели ввиду, видимо? https://blog.rust-lang.org/2023/01/20/types-announcement.htmlДык это такие же "проблемы", как и в любом другом развивающемся языке программирования.
>> we already had a crate published on crates.io before which used this bug to transmute in safe code, see #25860 (comment).
>> this issue is a priority to fix for the types team and has been so for years now. there is a reason for why it is not yet fixed. fixing it relies on where-bounds on binders which are blocked on the next-generation trait solver. we are actively working on this and cannot fix the unsoundness before it's done.
> А ты забавный. Тебе показывают, что язык дырявый. Ты даешь ссылку, что
> дыра существует 10 лет. Причем в обсуждении дыры прямо пишут, что
> у раста проблемы тайпчекером и системой типов. 10 лет.А ты еще забавней, проигнорировал ответ автора cvs-rs, проигнорировал сложность абуза этого бага (там "кастуют" и "магичат" с кусом памяти нулевого размера) в реальном коде,
зато обобщил этот баг в компилере как "язык дырявый". Ну да, то ли дело баги в GCC, всплывающие прям в регресс-тестах ядра,
https://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html
ага.Хотя открою тайну: полностью "sound" ЯПы либо остаются маргинальными академическими поделками, на которых никто не пишет, либо строчка кода, для тех же критических систем, обходится в очень нехилую сумму денег, плюс минимум еще столько же за верификацию "взаимодействия" этого кода с реальностю.
> проигнорировал ответ автора cvs-rs, проигнорировал сложность абуза этого багаНичего я не игнорировал. Вам дали ссылку на конкретый баг с полным описанием, как этот баг экплуатируется.
"Сложность" и "невозможность" находятся по разную сторону. Евангелистам не надо было распинаться про "невозможность", не тыкали бы этим проектом в лицо.
> Хотя открою тайну: полностью "sound" ЯПы
Я хорошо знаю сложность (NP) верификации алгоритмов, в том числе про сложность работы с памятью (NP). Поэтому резко против евангелистов rust с "безопасной работой с памятью". На данном этапе разития математики, науки и техники (формальную) корректность можно проверить только у небольшой программы.
Жду "следующего поколения"
>> проигнорировал ответ автора cvs-rs, проигнорировал сложность абуза этого бага
> Ничего я не игнорировал. Вам дали ссылку на конкретый баг с полным
> описанием, как этот баг экплуатируется.Какая занимательная реальность, в моей - это описание дал я сам, а воены супротив раста выдали лишь невнятное "ничего не гарантирует, вот!" ...
> Я хорошо знаю сложность (NP) верификации алгоритмов, в том числе про сложность
> работы с памятью (NP). Поэтому резко против евангелистов rust с "безопасной
> работой с памятью". На данном этапе разития математики, науки и техники
> (формальную) корректность можно проверить только у небольшой программы.Сложность NP решается ограничением на лишь определенное подмножество операций (ну вон, см. трудности реализации двусвязного списка в расте) и "ручной проверкой" всего остального. Это позволяет задействовать мощности компьюктеров для проверки хотя бы части кода, вместо заката солнца ручками.
Внезапно, да?
А то на идрисах, агдах и коках чей-то не видно программ общего-системного назначения ...
> А то на идрисах, агдах и коках чей-то не видно программ общего-системного назначения ...Не идрис, но хаскель - вон даже ОС запилили.
programatica.cs.pdx.edu/House/
Выглядит она конечно как привет из 90х, но ГУЙ можно и поменять.Тут вопрос в другом - сложность.
Да и найти программеров на хаскель сложно, там нужны мозги чтобы не погрязнуть в монадах и функторах.
А на СИ или PHP можно научить лабать даже камаку - поэтому они и распространенные.
ОС можно запилить на абсолютно любом языке программирования (полным по Тюрингу). Скорее всего, предыдущий высказывающийся имел ввиду эффективную с точки зрения использования машинных ресурсов ОС, а не просто ОС-прототип. Где-то попадались статьи, что на языках, поддерживающих исключительно функциональную парадигму программирования такое практически невозможно осуществить, ввиду сложности оптимальной реализации некоторых абстракций. Подробности, увы, уже не помню, статья попадалась лет 10 назад примерно.
Только для целевой атаки достаточно одной уязвимости. Подумай об этом. И про ложку дегтя в бочке меда. Не имеет смысла размер бочки если любое количество дегтя делает даже самую безопасТную бочку неюзабельной. Можно просто сэкономить на бочке.
> И про ложку дегтя в бочке меда. Не имеет смысла размер бочки если
> любое количество дегтя делает даже самую безопасТную бочку неюзабельной. Можно просто
> сэкономить на бочке.О, Воены Супротив Раста подтянули "тяжелую артиллерию" в виде натягиваемых на глобус аналогий.
Надеюсь, Воены пилят только ручной пилой (и используют такую же продукцию), а то ведь электро/бензопилу и всякие индустриальные лесопилки легко отыметь простым ломом, что делает их с точки зрения-"логики" Военов неюзабильными ...
Нет никаких военов. Есть только люди со здравым смыслом и это не ты. Кому безопасно есть питон, го, хаскель, джаваскрипт. Руст от них ничем в лучшую сторону не отличается.
Отличается производительностью выполняемого кода в той же когорте, что и C/C++.Раньше выбор стоял между крестиками и питоном (условно) и выбор состоял в безопасности против производительности.
Теперь выбор между растом и условным питоном. При этом выбор между скоростью написания кода и производительностью.
Со временем плюсы станут коболом. Куча легаси кода, который никто особо не хочет трогать кроме старичья.
Что? Опять кто то знает, как лучше, "молодое чудо" называет старичьём тех, кто для него <s>построил эту цивилизацию</s> прошёл по этой дороге и накопил все эти знания. Эх.
Удачи в воспитании благодарных учеников :)
> Что? Опять кто то знает, как лучше, "молодое чудо" называет старичьём тех,Э... а они бы без этого помолодели?
Есть четкие метрики, например возраст.
Про разрабов ядра говорили "We're getting old and gray"> кто для него <s>построил эту цивилизацию</s> прошёл по этой дороге и накопил все эти знания.
Т.е теперь даже критиковать нельзя?
Типа "дедушка так много сделал! не смей рассказать, что он писал код криво-косо!!"> Эх. Удачи в воспитании благодарных учеников :)
Я очень надеюсь, что мои ученики, не будут бездумно преклоняться перед дедом, тк я наделал кучу ошибок и набил дофига шишек.
ps напомню что мы говорим про поколение, которое устраивало войны во вьетнаме и афгане, расцвет наркоты, сегрегации и насильственные переселения и прочие веселые вещи
> Т.е теперь даже критиковать нельзя?
> Типа "дедушка так много сделал! не смей рассказать, что он писал код криво-косо!!"Те кто писал код не криво-косо - очевидно, не написали тот код, который все используют. Значит что-то делали не так.
Поэтому твоя критика просто показывает твой взгляд на мир - юношеский максимализм, весьма далекий от реальности.
>Поэтому проблемы если возникают, то именно unsafe блоках.А Rustonomicon говорит строго обратное, что unsafe - нелокален, и что от него проблемы могут возникнуть вообще где угодно.
> А Rustonomicon говорит строго обратное, что unsafe - нелокален,
> и что от него проблемы могут возникнуть вообще где угодно.Нет. Проблемы находятся именно в unsafe блоках.
А вот последствия этих проблем таки да не локальны и могут проявится везде.Как следствие при напр. неясном segfault нужно просмотреть только unsafe code, чтобы найти проблему, а не всю кодовую базу.
Нет, если у тебя есть один unsafe, то проблема может быть где угодно, не только в этом unsafe.pub struct Vec_u8 {
buf: *u8,
size: usize,
len: usize,
}impl Vec_u8 {
pub fn index(&self, i: usize) -> u8 {
assert!(self.len > i); // [1]
unsafe { *self.buf.offset(i) }
}
pub fn break_things(&mut self) {
self.buf = ptr::null(); // [2]
}
}[1] Если i < len, то тогда у нас buf валидный указатель, и buf+i тоже. Это базовый инвариант, которым мы организуем структуру данных. Компилятор не может проверить это сам, поэтому мы следим за ним по старинке, как диды в C делали. Тут я панику дёргаю в случае если индекс за границы выходит, но это исключительно для простоты, можно делать и интереснее, типа возвращать Option например, или расширять массив так, чтобы он содержал этот индекс. Это не суть, главное что unsafe блок ниже выполняется при гарантированном выполнении условия self.len > i.
[2] А тут мы берём и ломаем инвариант. После этого, вызов метода index приведёт к сегфолту. Сегфолт возникнет в unsafe блоке (self.len будет > 1, но ptr при этом невалидный), но баг-то вовсе не в нём, а тут.
Если ты дашь себе труд тыкнуть по ссылке src в документации на стандартный Vec и повтыкать в код, ты увидишь, что там есть немало &mut self методов, которые что-то там меняют внутри Vec, и _любые из этих изменений потенциально могут привести к сегфолту_, даже если они не используют unsafe.
И таким образом, если у тебя какой-нибудь из unsafe блоков Vec сегфолтнется, ты будешь искать баг во всём модуле. А если у тебя внешний код (по отношению к модулю) использует unsafe конструктор Vec, собирая Vec из указателя, size и len, то тебе придётся ещё и во внешнем коде искать причины возникновения Vec с порушенными инвариантами.
Риторический вопрос, сосед интересуется. Почему бы убрать unsafe в некоторых случаях чтобы вместо 7500 было бы 3500 unsafe функций. То есть переписать частично на safe rust, так и верифицировать меньше придётся. Раз оно что-то там не сходится, то значит не хватает абстракций. А то выходит если что-то не получается без unsafe, то просто используем его затычку и делаем чёрную магию.
> Поэтому проблемы если возникают, то именно unsafe блоках.Проблемы возникают на любом уровне, так как unsafe лишь косвенно влияет на них. Классический пример - использование MaybeUninit. Проблемы возникают при ошибках в его использовании, а вовсе не в самом unsafe блоке.
> Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках.
По вышеописанным причинам, верифицировать потребуется всё равно всю библиотеку. Даже контроль за входными параметрами осуществляется совсем не в unsafe блоке.
> А это почти в 5 раз меньше работы.
В той же glibc функций, в которых потенциально возможны угрозы, тоже не порядка 20% процентов. Так что тут паритет.
> Поэтому проблемы если возникают, то именно unsafe блоках.Проблемы возникают на любом уровне, так как unsafe лишь косвенно влияет на них. Классический пример - использование MaybeUninit. Проблемы возникают при ошибках в его использовании, а вовсе не в самом unsafe блоке.
> Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках.
По вышеописанным причинам, верифицировать потребуется всё равно всю библиотеку. Даже контроль за входными параметрами осуществляется совсем не в unsafe блоке.
> А это почти в 5 раз меньше работы.
В той же glibc функций, в которых потенциально возможны угрозы, тоже не порядка 20% процентов. Так что тут паритет.
Нет ничего иделаьного! А результат всяко лучше по сравнению с С/C++.
Если на стройке носить 10 касок подряд, то будет в 10 раз безопаснее! Но почему-то в реальности так никто не делает.
Кривая аналогия. Правильной была бы такая. На стройке желательно носить каску, защитные очки, перчатки строительные, спецодежду, страховку (если ты высотник).
> Если на стройке носить 10 касок подряд, то будет в 10 раз безопаснее!А почему 10, а не 20?
Если при думывать глупые аналогии, то почему не доводить до абсурда?> Но почему-то в реальности так никто не делает.
Конечно не делают.
С/С++ это вообще без каски, страховки и, как выясняются никто не читал правила ТБ (стандарт).
В общем рабочие прыгают на арматуру, котрую пилять болгаркой без кожуха, крановщик роняет плиты, сварщик варит без очков-маски, бетономешалка мешает бетон, бригада строителей пьет...И кстати "в реальности" при первом же C̶V̶E̶ факапе, всех ответственных будут набутыливать.
Жаль в софте пока AS IS, и никакой ответственности за овнокод нету((
А теперь представим что unsafe нет, и нужно перелопатить 35к функций, вместо 7500 если бы unsafe был.
Там и так нужно перелопатить 35к, уб в расте есть везде. Не говоря о том, что многие из этих 35к - хэлворды.
UB в расте не может быть за пределами unsafe блока. Это гарантированно. Все остальное он конечно не гарантирует, например утечки памяти.
Эти гарантии уже умножены на ноль. Кидал ссылку ниже.
Семантика языка, которая гарантирует безопасность, это всего лишь описание. Но конечно многое зависит от компилятора и его уязвимостей которые всегда есть. И этот проект по сути их демонстрирует.
Он демонстрирует что в расте нет никакой необходимости. Дешевле писать на нормальных языках. Сейф на питоне, ансейф быстрый код на с++ как модули для питона. Все экономия 1000%
Питон на реальных задачах в сотни раз медленее Си. Лучше уж Java или C#.
Куда ты так торопишься задача ты моя? Так можно и успеть.
> Он демонстрирует что в расте нет никакой необходимостиНаверное, поэтому правительство штатов приказало предоставить план отказа от C/C++ к 2026 году.
Сколько безосновательных заявлений в одном предложении. Фирмы, мировые лидеры в сфере разработки софта, демонстрируют, что в Rust есть необходимость, и на нём писать дешевле, чем на Плюсах. Как демонстрируют? Пишут отчёты с циферками.
> Фирмы, мировые лидеры в сфере разработки софта, демонстрируют, что в Rust есть необходимость, и на нём писать дешевле, чем на Плюсах. Как демонстрируют? Пишут отчёты с циферками.Предполагаю ответы будут такие или из подобного списка:
1. Это все корпы они только все портят и выбрасывают
2. Корпы хотят монополизировать разработку!
3. Это подделанные отчеты - никто не будет пользоваться растом, они просто врут чтобы получить премию!
4. Это все заговор содомитов!!
...
N. Абырвалг! Абырвалг!
> N. Абырвалг! Абырвалг!Вот воследнее - это как раз ваш уровень.
Но верить цифиркам - которые рисуют менеджеры явно зависящие от того, какие циферки они нарисуют (ибо решение о внедрении приняли они и за счет отчетов уже получили повышение), говорит об полном отсутствии критического мышления.
И да. Такие как вы - еда для мошенников.
>Это гарантированно.Кем или чем?
Компилятором и RFC
Почему нельзя сразу написать безопасно. Если есть ансейф то язык уже небезопасен.
Можно, но это либо дорого либо неэффективно.
>то язык уже небезопасенВсё-таки с логическим мышлением у вас проблемы. Не язык в целом, а часть кода на языке с пометкой unsafe.
Надо теперь всё с Rust переписать на SPARK, чтобы было надёжно и верифицируемо.
Unsafe был введён более пяти лет назад (https://github.com/rust-lang/rust/commit/10855a36b53d33aa2e4...), и за это время люди успели использовать этот ключевое слово в множестве проектов. Однако только сейчас они начали заниматься его верификацией. Ну что ж, подход к безопасности действительно "на высшем уровне".
Верифицируют библиотеку, а не unsafe.
Но ведь адепты говорили что факт написания ансейфа будет помогать программисту сильнее концентрироваться на ошибках в коде, а оказывается не помогает. И хакер все равно выйдет за границы и возьмёт рута. А уязвимость поправят только через 5 лет во время какой-то там верификации. Причем найдут только 1 из 10 уязвимостей.
> Но ведь адепты говорили что факт написания ансейфа будет помогать программисту сильнее
> концентрироваться на ошибках в коде, а оказывается не помогает. И хакер
> все равно выйдет за границы и возьмёт рута.А гугол-то в курсе?
https://www.opennet.me/opennews/art.shtml?num=61933
> Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android...
> Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году---
> А уязвимость поправят только через 5 лет во время какой-то там верификации. Причем найдут только 1 из 10 уязвимостей.
Опять методика 'Пальцем в небо' сертифицированного сотрудника 'НИИ Кекспертизы и вбросов' им. Опеннета?
Опять повысились надои? А новость сабжевую ты прочитать не хочешь? Чтобы найти вульны нужна аш целая инициатива от целого Амазона. Без этого вульны не ищутся.
> Опять повысились надои? А новость сабжевую ты прочитать не хочешь? Чтобы найти
> вульны нужна аш целая инициатива от целого Амазона. Без этого вульны
> не ищутся.Опять альтернативная реальность? А то в нашей гугол платит нехилые бабки за каждый найденый вулн:
https://opennet.ru/opennews/art.shtml?num=60780
> Из потраченной в 2023 году суммы $3.4 млн (в прошлом году $4.8 млн) выплачено за уязвимости в Android. За информацию об уязвимостях в браузере Chrome было выплачено 359 премий на общую сумму $2.1 млн (в прошлом году $3.5 млн).Че там кстати с твоими чиселками? Я угадал с методикой очередного статистического опеннетного исследования?
Что та скоростью разработки в 10 раз медленнее? Серво уже дописали? Или может редокс?
> Что та скоростью разработки в 10 раз медленнее?Вот, очередное проявление дремучей невежественности. Скорость разработки, если судить по отчётам сотрудников Гугл и не только выросла по сравнению с разработкой на C++! Качество кода тоже существенно улучшилось.
>Серво уже дописали?
Mozilla продолжает использовать Rust в коде своего браузера.
> Или может редокс?
Redox - это домашний проект. Но эта ОС уже может запускаться на реальном железе. Это в вашем понимании уже дописали?
Вот очевидно проявление дремучей невежественности.Не сотрудников google, а менеджера. Который внедрил - лишь что-нибудь внедрить, нарисовал отчеты и получил повышение.
Стоит критичнее относится к источникам информации.
Плюсовый код 100% unsafe, в проде уже 25 лет -- и ни разу не видел что-бы хоть кто-то заморачивался с его верификацией дальше академико-теоретических кругов.
https://github.com/Speykious/cve-rs - там уб в сейфе, толку валидировать ансейф.
Ага, со своей версий transmute. Из стандартной библиотеки "не подошла".https://github.com/Speykious/cve-rs/blob/main/src/transmute.rs
Хоть со своей, хоть с чьей-то ещё. Заявляется безопасность кода на языке, а не либы - подучи логику. Ансейфа нет, проблемы есть.
>> cve-rs also contains safe reimplementations of:
>> std::mem::transmute
>> std::ptr::null()/null_mut() but for references
>>> pub const unsafe extern "rust-intrinsic" fn transmute<Src, Dst>
>>> Reinterprets the bits of a value of one type as another type.
> Хоть со своей, хоть с чьей-то ещё. Заявляется безопасность кода на языке,
> а не либы - подучи логику. Ансейфа нет, проблемы есть.Кекспертизм опеннетный, аз из
Да и то, что для появления проблем (т.е. чтобы найти баг в компиляторе - ведь "работатет" оно только с кастомным null/transmute) там целый консилиум корпел не одну неделю (см. обсуждение на гитхабе) - кексперты скромненько умалчивают.
И правда, какая разница: заиметь UB после траха^W написания кастомного null и принудительного каста типа данных - или заиметь UB, просто сложив два числа или забыв пустую строку в конце исходника ...
Всё, ответов не будет? С одного вопроса потеряться - мощно.> cve-rs also contains safe reimplementations of
> safe reimplementationsМолодец, умножил на ноль тезисы предыдущего героя. Хоть не зря кучу левого мусора спастил.
> Всё, ответов не будет? С одного вопроса потеряться - мощно.Не суметь прочесть три предложения и сразу перейти к "папа, где море?" - намного уныл^W мощнее.
>> cve-rs also contains safe reimplementations of
>> safe reimplementations
> Молодец, умножил на ноль тезисы предыдущего героя. Хоть не зря кучу левого мусора спастил.Молодец, обозвал сигнатуру transmute "левым мусором" и не сумел написать ничего по существу ... зато выдал хороший, объемный выхлоп метана - Газпром гордится тобой!
Следует отличать хак, найденный в компиляторе, от намеренного UB в стандарте (sic!) языка программирования. Вы там чуть ниже про логику говорили...
У раста нет стандарта. Ты с логикой поссорился ещё очень много лет назад.
Я про стандарты в таких языках, как Си, Си++
ниже -> ранее
21yoseniorУ Rust нет спецификации, но есть RFC. Принципиальной разницы на вижу, как и, например, группа разработчиков Gcc,которые работают над своей версией компилятора.
Говоря о стандартах, я имел ввиду не Rust, а C, C++.
Про какое "воровство" вы тут говорите?
> Про какое "воровство" вы тут говорите?Я написал про какое. Приведены противоречия лозунгов("гарантирует" и прочее) с реальностью(никаких гарантий). Что ты мне отвечаешь? - "а вот в сишке уб". Никто не спрашивал тебя про сишку, тебя спрашивали про враньё. Но ты начал прятаться за сишку, пытаясь съехать с темы.
RFC мусор, который ничего не описывает. Можешь показать мне описание модели памяти в расте. Это принципиальная разница.
> Приведены противоречия лозунгов("гарантирует" и прочее) с реальностью(никаких гарантий).Вы привели просто баг в компиляторе. Ничего более. Если предположить, что его нет (раньше или позже исправят), гарантия будет соответствовать реальности. Собственно, она (гарантия) и сейчас соответствует реальности в 99.999999999% случаев (а может даже ещё чаще). Почему? Потому что вот тот баг, который вы привели, он создан искусственно и в РЕАЛЬНОМ коде вы такое никогда не встретите.
> Что ты мне отвечаешь? - "а вот в сишке уб".
Вы не со мной общались на эту тему по большей части. С Аноним(45) и с Аноним(-). Это другие люди. Я вам сразу заявил, что ваша ссылка - это просто БАГ (а не фича) компилятора.
> RFC мусор, который ничего не описывает.
И как же тогда разработчики GCC на основе этого "мусора" решились создать свой компилятор?
>И как же тогда разработчики GCC на основе этого "мусора" решились создать свой компилятор?Ну если эти RFC окажутся неясными/неполными, то получится диалект GNU/Rust.
> Ну если эти RFC окажутся неясными/неполными, то получится диалект GNU/Rust.Влажные фантазии типичного кексперта. А по факту:
https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
> If gccrs interprets a program differently from rustc, this is considered a bug.В репозитории раста есть обширний набор тестов, которые можно использовать для проверки совместимости.
Покажешь мне стандарт раста. Иди погугли, вернёшься как найдёшь.К тому же, в очередной раз заходы уровня "а у вас негров линчуют". Кто-то говорил здесь про сишку и прочие языки? - нет. Но данный пропагандист почему-то начал прятаться за ними.
Это кстати, фундаментальное свойство. Раст состоит из воровства не только по части семантики/компилятора/рантайма/прочего, но также из воровства обоснований своей состоятельности. То есть без пряток за сишку даже сказать никто не смог, что из себя представляет раст и зачем он нужен.
> Это кстати, фундаментальное свойство. Раст состоит из воровства не только по части семантики/компилятора/рантайма/прочего,ого, ну у тебя бомбануло!
а какой компилятор украли?
его сначала на окалме писали, потом на самом расте..
даже бекенд на самом расте уже есть> но также из воровства обоснований своей состоятельности.
Ты часом не бухаешь? а то логика как-то хромает.
> То есть без пряток за сишку даже сказать никто не смог, что из себя представляет раст и зачем он нужен.
Для того чтобы сравнить что-то, нужно минимум два операнда.
Раст избавляет от типичных ошибок памяти... в чем?
в си/с++, а аде и фортране такого же нет.
> Покажешь мне стандарт раста. Иди погугли, вернёшься как найдёшь.Надеюсь, вы справитесь с тем, чтобы прочитать все мои ответы в этой ветке. Когда осилите (хотя есть большие сомнения на этот счёт), приходите, продолжим беседу.
Кстати, вас родители не научили, что тыкать незнакомым людям - невежливо? Или вы всё ещё в процессе этой учёбы?
> Компания Amazon и организация Rust Foundation представили инициативуТолько один вопрос. Кто им разрешил?
А кто запрещал?
Хороший вопрос! Иногда кажется, что разрешение не требуется.
Вопрос не праздный. Вспомним Ada, созданный МО. Да, он есть, но связываться с ним как-то не хотелось и не хочется. За Rust также топит МО. И это тоже как бы намекает. Последствия будут, если не сейчас, так потом. Смотреть надо не сиюминутные выгоды, а на перспективу.
Наверное, лучше остаться на относительно свободном C/C++, в том числе для новых проектов.
>За Rust также топит МО.Но не оно является создателем языка, и не оно создаёт компилятор.
>И это тоже как бы намекает. Последствия будут, если не сейчас, так потом.
Например, какие?
>Наверное, лучше остаться на относительно свободном C/C++, в том числе для новых проектов.
Группа разработчиков Gcc работает над компилятором Rust, если вы о вендорлоке.
> Например, какие?Экспортные ограничения.
МО не занимается вопросами экспорта.
А ещё она медицинскую помощь нелегальным мигрантам не оказывает. Давай больше бессвязных фактов.
> МО не занимается вопросами экспорта.Безусловно. Вопросами ограничения занимается.
Ок. Назовите хотя бы пяток свободных компиляторов C. Заодно назовите страну, где находится исходный код этих компиляторов.
> Группа разработчиков Gcc работает над компилятором Rustэто фиктивный костылёк чтобы можно было собрать ядро Linux. Полноценный компилятор есть и будет только один под полным контролем корпораций и учитывая что там не GPL тухлый вариант чтобы с ним связываться.
Тем более нет никаких методик как определить что gcc компиль раста работает так же как штатный компиль раста. И на какую именно версию компиля gcc ровняется на 1.10 или 1.20.
Вы уже не первый, и, видимо, не последний человек, говорящий про контроль корпораций над чем-то. Хочу вам открыть страшную тайну, только обещайте никому не говорить. Так вот. Все сколь-либо крупные проекты контролируются корпорациями в той или иной степени.И никакая GPL вам не поможет, если корпорации решат перекрыть доступ к открытому ранее коду, даже если у вас будет возможность форкнуть этот самый код. Почему? Потому что создание сколь-либо сложного, годного в употребление ПО требует немалых усилий. Как показывает многолетняя практика, так называемое сообщество не в состоянии без контроля со стороны корпораций тянуть подобные проекты. И они быстро протухают.
> И никакая GPL вам не поможет, если корпорации решат перекрыть доступ к открытому ранее коду, даже если у вас будет возможность форкнуть этот самый код.GPL не позволяет закрыть общий код, разве это непонятно ? Пример Linux - вспотеешь его закрывать на законных основаниях потому что для этого потребуется сменить лицензию а для этого потребуется согласие всех участвоваших в разработке - права на код остаются у авторов.
> Как показывает многолетняя практика, так называемое сообщество не в состоянии без контроля со стороны корпораций тянуть подобные проекты.
мне вообще фиолетово что они там контролируют у Linux - они пишут код для меня и закрыть его не могут. С компиляторами на шланге совсем подругому - оптимизированные компиляторы платные и закрытые (arm compiler, xtensa compiler) а тебе ну может морковки подкинут немного.
> GPL не позволяет закрыть общий код, разве это непонятно ? Пример Linux - вспотеешь его закрывать на законных основаниях потому что для этого потребуется сменить лицензию а для этого потребуется согласие всех участвоваших в разработке - права на код остаются у авторов.Похоже, вы не до конца поняли мою мысль. Вот был проект X, которым владела корпорация Y. На определённом этапе код закрывается. Не тот, который под GPL был написан, а новый код, который добавляет дополнительные фичи. И? Что вы будете делать? Полагаться на сообщество? Я уже написал, оно не потянет. Единственным выходом будет, что такой проект форкнут и потянут уже другие корпорации. Но вы же ярый противник корпораций. Или уже нет?
> они пишут код для меня и закрыть его не могут
Очень даже могут. Новый код. Не старый, конечно же. Вон, драйвера НВидии, например. Они открыты, несмотря на то, что есть для Линукса?
> Похоже, вы не до конца поняли мою мысль. Вот был проект X, которым владела корпорация Y.это не мысль а подмена понятий, проектом владеет коммерческая компания и даже если у него есть вариант с открытой лицензией это не открытый проект как Linux а хрень с двойной лицензией, краник перекрыть могут в любой момент
> Очень даже могут. Новый код.
для этого надо отделить от него старый - давай попробуй, есть примеры для Linux ?
> драйвера НВидии, например.
это не часть ядра, драйверы GPU работают в юзерспейс, в ядре только малая часть управляющая памятью и имеющая доступ к аппаратным интерфейсам
> это не мысль а подмена понятийГде ж тут подмена понятий? Каким конкретно проектом владеет коммерческая компания? Владелец торговой марки Rust, компилятора и документации - Rust Foundation. И это не коммерческая компания. Да, туда входят корпы, точнее, являются спонсорами этой организации. Но и в организацию по созданию ядра Linux тоже входят корпы.
> для этого надо отделить от него старый - давай попробуй, есть примеры для Linux ?
Зачем что-то отделять от чего-то? Вы про модульность в программировании хоть что-нибудь знаете? Достаточно просто новые модули (библиотеки) писать с использованием закрытой лицензии. И всё. Весь прежний код останется открытым. И его даже можно будет форкнуть. И продолжать пользоваться. Однако новых фич вы в открытых исходниках уже не увидите. Неужели так просто понять эту несложную мысль?
просто -> сложно
> Где ж тут подмена понятий? Каким конкретно проектом владеет коммерческая компания? Владелец торговой марки Rust, компилятора и документации - Rust Foundation. И это не коммерческая компания.речь была про GPL, там где вы рассказывали "Вот был проект X, которым владела корпорация Y", в случае rust лицензия позволяет не открывать ничего изначально
> Вы про модульность в программировании хоть что-нибудь знаете? Достаточно просто новые модули (библиотеки) писать с использованием закрытой лицензии.
ну понятно что вы никогда не писали, хелловорд для себя можете попробовать с любой лицензией и никому не показывать, проблема возникнет когда вы попробуете выйти на рынок с лицензионно нечистым продуктом, в случае с Linux даже азиаты публикуют исходники, про европу и америку и говорить нечего
> в случае rust лицензия позволяет не открывать ничего изначальноНо он открыт. И это ваше "не позволяет" применимо к любому проекту, который продолжает развиваться.
> проблема возникнет когда вы попробуете выйти на рынок с лицензионно нечистым продуктом, в случае с Linux даже азиаты публикуют исходники, про европу и америку и говорить нечего
Что значит лицензионно нечистым? Ещё раз. Медленно. Часть кода открыта. Другая часть - нет. Обе части лицензионно чисты. Просто лицензии разные. Вполне себе распространённая практика. И ничего, люди пользуются. Драйвера НВидии для Линукса - это как раз из этой оперы. Да, они не часть ядра, просто, скажем с некоторой натяжкой, отдельный модуль. Но этот модуль закрыт. Точка. А люди продолжают им пользоваться, тем не менее.
Далее. Никакой проблемы не будет, если а) функциональность, предоставляемая закрытой библиотекой (модулем), восстребована на рынке; б) нет открытых полноценных аналогов.
> отдельный модуль. Но этот модуль закрытне надо сказки рассказывать - модуль ядра открыт
https://github.com/NVIDIA/open-gpu-kernel-modules
юзерспейсная часть закрыта. Ещё раз медленно - драйверы GPU работают в юзерспейс, в ядре только небольшая интерфейсная часть, её и закрывать то нет смысла.
Как насчет верификации хлама, который cargo тащит из-за бугра?
В суверенных проектах его использовать нельзя.
Пишите свой хлам, размещайте на госуслугах. Cargo поддерживает такое.
Это ты сейчас смеёшься, а когда всех пересдачи принудителтно на OneScript я на тебя посмотрю.
> Это ты сейчас смеёшься, а когда всех пересдачи принудителтно на OneScript я
> на тебя посмотрю.А что на меня смотреть-то? Я покинул зону поражения OneScript'ом.Тебе же предлагаю случать "Научно-технический рэп", трек "Язык для славян" )))
Ещё один человек не осилил поднятие репозитория
Не могу я понять растохейтеров. Впервые появился инструмент, позволяющий безопасно работать с памятью без ГЦ, без потери производительности, а они только критикуют. Самое смешное, что они критикуют Раст за то, что он не спасает от всех ошибок. "Что ж за безопасность, от всего не защищает, поэтому лучше останусь на Си". Логика классная, да, чем получить хоть какую-то защиту, буду шпарить дальше на абсолютно незащищённым Си.
Без какой потери производительности? Тесты посмотри. Магии не бывает.
> Без какой потери производительности? Тесты посмотри. Магии не бывает.Ну, посмотрел https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
что дальше? "Неправильные тесты, нещитаица!"?
О да тесты на домене 4го уровня. А самому головой подумать? Или как ты делаешь дополнительную работу не задействуя дополнительных команд процессора?
Э.. на этапе компиляции?Если у тебя типы провепяются во время компиляции, если элемент Enum у тебя можно отличить от другого перечисления (и это не задекорированный int как в других языках), если у тебя есть проверки инвариантов, если проверки на null...
Да скорость сборки у тебя замедлится, но выполнение может быть на том же уровне.
> тесты на домене 4го уровняДругих аргументов, полагаю, нет и не будет.
Читай до полного усвоения https://habr.com/ru/articles/598219/
> Читай до полного усвоения https://habr.com/ru/articles/598219/Ты бы сам прочитал, а то вышел неловкий пук в лужу с твоим rustmustdie:
https://www.opennet.me/openforum/vsluhforumID3/126424.html#247
https://www.opennet.me/openforum/vsluhforumID3/126424.html#270
Ну, брать дебаг-релиз и сравнивать с gcc-шным выхлопом -O0, как бы уже намекает на уровень (ламерства) ...
> Читай до полного усвоения https://habr.com/ru/articles/598219/Кстати, вдогонку насчет рантайма и дабы немного подогреть бедных военов (а то зима, лужи ведь холодные):
https://www.opennet.me/openforum/vsluhforumID3/124921.html#322++++++
> Сколько весит хелло ворд на русте с зависимостями?500 байт
$ cat hello.rs
#![no_std]
#![no_main]
use core::panic::PanicInfo;
use syscall::syscall;#[panic_handler]
fn panic(_info: &PanicInfo) -> ! { loop {} }#[no_mangle]
pub extern fn _start() -> ! {
let message = "Hello World\n".as_bytes();
unsafe {
syscall!(WRITE, 0, message.as_ptr(), message.len());
syscall!(EXIT,0);
}
loop {}
}
$ ./hello
Hello World$ ll hello
-rwxr-x--- 496B 30 Jul. 12:41 hello*
$ readelf -d hello
There is no dynamic section in this file.
$ objdump -d hello
Disassembly of section .text:00000000004000b0 <.text>:
4000b0: 55 push %rbp
4000b1: 48 89 e5 mov %rsp,%rbp
4000b4: 6a 04 pushq $0x4
4000b6: 58 pop %rax
4000b7: 6a 09 pushq $0x9
4000b9: 5a pop %rdx
4000ba: be cc 00 40 00 mov $0x4000cc,%esi
4000bf: 31 ff xor %edi,%edi
4000c1: 0f 05 syscall
4000c3: 6a 01 pushq $0x1
4000c5: 58 pop %rax
4000c6: 31 ff xor %edi,%edi
4000c8: 0f 05 syscall
4000ca: eb fe jmp 0x4000caПриходи, когда найдешь тут рантайм.
Они специально так сделали. Показуха. Нужно смотреть более серьёзные программы чем вывод строчки текста на экран.
А ты что из своего раста дергаешь наши Сишные сисколы? Напиши свои на расте, а потом сравнивай уже.
Типа Rust - это сферический конь в вакууме? Или что вы хотели сказать? Если сравниваете программу на C, которая дёргает системные вызовы, то почему то же самое запрещено делать на Rust? Надо ведь сравнивать сопоставимые вещи, не правда ли?
Тебе намекают что в Раст нет необходимости. Есть языки которые делают тоже самое и даже лучше и на них уже все написано.
> Тебе намекают что в Раст нет необходимости.Ну какой-то недалёкий человек на что-то там намекает. Нужно ли мне обращать на это внимание? Я предпочитаю принимать во внимание мнение фирм-лидеров в разработке ПО, а не каких-то анонимных экспертов, которые, скорее всего, ни строчки кода не написали для ПО системного уровня.
> Есть языки которые делают тоже самое и даже лучше и на них уже все написано.
Сходных по характеристикам с Rust - пока нет. Что это за характеристики? Минимальный рантайм (или даже практически полное отстутствие такового), гарантии по безопасной работе с памятью, строгая статическая типизация, алгебраические типы, исчерпывающий паттерн-матчинг, поддержка Юникода из коробки, и ещё, хотя это уже не о языке, но всё же - отличная инфраструктура.
В догонку он пишет... Смысл статьи на хабре исключительно про то что чтобы раст был более мене похож на си по скорости нужно очень сильно раст оптимизировать. Ясное дело в проде такое не используют у всех толстые раниаймы оптимизация только для липовых тестов для фанатиков.
> В догонку он пишет... Смысл статьи на хабре исключительно про то что
> чтобы раст был более мене похож на си по скорости нужно
Сама статья короткая, но постулирует довольно большой список спорных утверждений, а именно:Стандартная библиотека неотделима от языка
У него отсутствует нулевой рантайм
В Rust встроен сборщик мусора
Компилятор генерирует медленный машинный код
На самом деле набросов еще больше, но достаточно и этого списка.К сожалению, для опровержения этих пунктов мне придется писать максимально уродские хэлло ворлды, которые только можно представить.
Хм, т.е. статью ты не читал. Что видно уже по фантазиям "похож на си по скорости".
Так-то, там (хабр) автор зачем-то заморочился с собственной реализацияей crt* и сисколов (которые в сишном примере - ничуть не меньше по объему, просто вынесены в отдельные файлы).А вон то выше - вполне на раз опровергает все пункты.
То что автор героически решил проблемы которые есть и доказывает наличие проблем. Но ты конечно же и бревно у себя сзади на заметишь.
> То что автор героически решил проблемы которые есть и доказывает наличие проблем.Конкретный список проблем в студию. А то у тебя то "скорость", то "рантайм" - но, как обычно, ничего конкретного.
> Но ты конечно же и бревно у себя сзади на заметишь.Ух, очередная аргументативная аргументация Военов.
Ну подумай какая проблема есть у тормозного и небезопасного языка Раст.
Тормозной и небезопасный он только в вашем богатом воображении (мягко охарактеризуем его так). На практике же он и безопасный, и быстрый. О чём и свидетельствует опыт фирм мировых лидеров планеты в области разработки ПО.
>То что автор героически решил проблемы которые есть и доказывает наличие проблем.Какие проблемы? Вначале сишники над каждым байтом трясутся, использование нулевого терминатора, это ж какая экономия, а потом спустя лет пятьдесят изобретают некое подобие голанга, так как за все годы, они так и не научились не портить память (https://www.opennet.me/opennews/art.shtml?num=62241).
> О да тесты на домене 4го уровня.О, опоздавший родиться и не слышавший о "The Computer Language Benchmarks Game", зато топящий за сишку? Ну, бывает, особенно у неофитов.
> А самому головой подумать? Или как ты делаешь дополнительную работу не задействуя дополнительных команд процессора?
Короче, тестов сравнимых по качеству хотя бы с бенчмарк-геймом не будет, будет лишь вода и "нещитаица".
>зато топящий за сишку? Ну, бывает, особенно у неофитов.Неофит - новый сторонник какой-либо религии.
Новыми можно назвать адептов Rust.
Так что, как то, неправильное употребление слова.
Он ещё даже вуз не окончил, а уже пытается умные слова употреблять.
Хорошо, что вы ВУЗ закончили. Плохо то, что это времяпрепровождение прошло для вас бесцельно.
По себе судишь не надо так.
Я по себе никогда не сужу. Потому что умный и образованный. Просто гляжу на ваши потуги троллинга тупостью, и они меня печалят.
Придирки к одному единственному слову, игнорируя общий смысл сказанного... Таки он прав в том, что религиозны не программисты на Rust, а программисты на C. И вы - яркий тому пример.
>Неофит - новый сторонник какой-либо религии.
>Новыми можно назвать адептов Rust.С чем воевали хейтеры раста, до появляения раста? С хаскелем? Окамлом? Логикой?
С любыми проявлениями фанатичной религиозности.
Подгонять что угодно под тесты любимая задача для очковтирателей.
> Неофит - новый сторонник какой-либо религии.
> Новыми можно назвать адептов Rust.А Воены Супротив Раста - это члены древнего и уважаемого Ордена Защиты Вселенной от Ржавой Угрозы, ага.
> Без какой потери производительности? Тесты посмотри. Магии не бывает.
> Подгонять что угодно под тесты любимая задача для очковтирателей.А ты самокритичен! Правда, тесты так и не предоставил.
Ну и не очень понятно, какие именно религиозные обеты не дают написать Военам более правильные тесты на правильных ЯП в Shootout-e?
В любой прикладной задаче, где потребуется передать владение каким-либо массивом объектов или их свойств, раст сразу садится а лужу.
В этом случае есть варианты: отстрелить ногу в ручном управлении памятью, позвать на помощь GC. Интересно, что же выберут сишники?
>Без какой потери производительности? Тесты посмотри. Магии не бывает.Про zero cost дремучие люди не слышали?
> Впервые появился инструмент, позволяющий безопасно работать с памятью без ГЦ, без потери производительности, а они только критикуют.Потому что раст не позволяет безопасно работать с памятью и теряет производительность.
Но что более важно раст добавляет кучу других минусов: он очень архаичен в синтаксисе и дизайне, его напрямую контролируют 3 корпорации зла (что может пойти не так?), его архитектура и дизайн его экосистемы бездарна (объединим линтер и компилятор, что может пойти не так? почему бы не добавить в язык еще язык макросов, вместо того чтобы избавиться от них...), у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает).Ты предлагаешь отказаться от одного архаичного и уже состоявшегося языка с поддержкой примерно везде ради другого архаичного языка, не менее дырявого, но при этом с явными новыми проблемами. Так еще и у языка вполне себе конкретные владельцы которые в любой момент прикроют лавочку. А главный аргумент почему нужно перейти это весьма узкие проблемы при работе с памятью и то только для программ где не важна производительность. Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеля или на управляемые вроде питона или джавы или уже смириться и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблере.
Если уж и менять стек, то на что-то адекватное, а не на это маркетинговое !@#$%.
> Самое смешное, что они критикуют Раст за то, что он не спасает от всех ошибок. "Что ж за безопасность, от всего не защищает, поэтому лучше останусь на Си". Логика классная, да, чем получить хоть какую-то защиту, буду шпарить дальше на абсолютно незащищённым Си.
Незащищенным от чего? Где используют? В 99% либо используют либы на современных плюсах, где большинство проблем решены, и нет смысла менять стек на раст чтобы получить в моменте больше проблем, а в перспективе получить еще больше проблем.
> он очень архаичен в синтаксисе и дизайнеИ что же архаичного в синтаксисе и дизайне Раста? Он напротив современен - в нем, к примеру, подчеркивается стремление к иммутабельности переменных, чисто функциональная идея, которая пошла в мейнстрим лишь недавно.
> раст не позволяет безопасно работать с памятью
Позволяет. Недаром борроу-чекер есть
> теряет производительность.
Незначительно. В Расте нет ГЦ, во время компиляции всё просчитывается благодаря борроу чекеру, поэтому накладных расходов если и больше чем в Си, но сильно меньше, чем в Джавах и прочих Гоу. Уверен, компилятор Раста в дальнейшем может и перегнать сишку.
> Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеля или на управляемые вроде питона или джавы или уже смириться и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблере.
Хаскелл да, респект, функциональное программирование я уважаю. Но вот с питоном и джавой - суть как раз в том, что мы получаем те же гарантии по памяти, что в питоне и джаве, но без медленного ГЦ
> у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает).
Так борроу чекер да, и есть киллер-фича. Он снимает столько проблем, что уже обеспечивает полезность Раста.
В целом не могу понять, откуда у вас эта мантра про "нет производительности, лучше уж джава". Да Джава ж медленее гораздо.
Ну так вставь борроу чекер в GCC, тебе же никто не мешает. И раст сразу становится ненужон.
Только вот кода под этот самый gcc с борроу чекером нет и не будет.
> Потому что раст не позволяет безопасно работать с памятью и теряет производительность.Проверка работы с памятью проводится на этапе компиляции, а не на этапе выполнения. Поэтому нет, программы на Раст в производительности обычно не теряют (кроме отдельных специфичных случаев, таких, например, как цикл по массиву, в котором происходят проверки на выход за границы диапазона, но эти проверки при определённых навыках можно обходить).
> он очень архаичен в синтаксисе и дизайне
Надеюсь, вы понимаете смысл слова "архаичен"? Rust и 20 лет нет. Поэтому его синтаксис никак нельзя назвать архаичным, в отличие, например, от синтаксиса того же C.
> его напрямую контролируют 3 корпорации зла (что может пойти не так?)
Не контролируют, а спонсируют разработку. Да, могут отказаться от финансирования. Но это с любым проектом такое может произойти в нашем мире.
> его архитектура и дизайн его экосистемы бездарна (объединим линтер и компилятор, что может пойти не так?
И что же?
> почему бы не добавить в язык еще язык макросов, вместо того чтобы избавиться от них...)
Зачем в C макросы используют? Или в Плюсах? И почему в Rust макросы - лишние, по-вашему?
> у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает)
По сути, вы вообще ничего не знаете об этом языке, а так смело и безаппеляционно о нём высказываетесь почему-то. Что, впрочем, неудивительно для "экспертов" местного пошиба. Алгебраические типы данных, безопасная работа с памятью, строгая типизация, контроль выхода за пределы массива, встроенные макросы, поддержка разных парадигм программирования, исчерпывающий паттерн-матчинг, отличные стандартные типы из коробки, поддержка Юникод из коробки, 0-cost абстракции... И так далее, и тому подобное.
> Если уж и менять стек, то на что-то адекватное
Например?
> а не на это маркетинговое !@#$%.
Гугл, Амазон, Клаудфлэр, Дискорд, Дропбокс и некоторые другие так не считают почему-то. Не задумывались почему?
> Незащищенным от чего?
Вы читать хоть немного не пробовали, прежде чем писать подобные утверждения или задавать подобные вопросы? От ошибок работы с памятью. От UB. От нестрогой типизации.
Всяк кулик своё болото хвалит. Вакансии есть? Нет. Лесом.
Вобще-то есть. Кто ищёт, тот найдёт. Это первое. Второе. Надо не только на вакансии смотреть, а ещё нравится ли лично вам тот или иной язык программирования. Если не нравится, а вы бегаете исключительно за зарплатой (никакого удовольствия от работы), мне вас искренне жаль. Очень быстро спалите свою психику, лимбическая система не выдержит.
>Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеляИз всех типизированных функциональных языков вы выбрали один из самых неповоротливых.
>или на управляемые вроде питонаСпасибо, не надо
>или джавыНа чём реализовать саму джаву? А операционную систему для джавы?
>и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблереСтараться не значит достичь. Сейчас в таких программах вагоны уязвимостей.
>Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеляИз всех типизированных функциональных языков вы выбрали один из самых неповоротливых.
>или на управляемые вроде питонаСпасибо, не надо
>или джавыНа чём реализовать саму джаву? А операционную систему для джавы?
>и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблереСтараться не значит достичь. Сейчас в таких программах вагоны уязвимостей.
Это люди из анекдота про реку с пираньями и мост с надёжностью "всего лишь" в 99,99%.
Просто не правильно рассчитывали вероятность. Правильно было: или сломается, или нет, т.е. 50%
>Впервыезвездёшь
>позволяющий безопасно
снова звездёшь
>без потери производительности,
опять звездёшь
Просто ребятки с помощью маркетинга пытаются сделать монополию в системной разработке,
чтобы потом их кривулькину идею пришлось всем доробатывать, ибо альтернатив нет, а они бы
ещё и руководили всем этим процессом.но технарей по началу можно поймать на маркетинг, а потом они стали задавать вопросы
Где ж маркетинг, если это всё очевидности. Си - вообще не даёт никаких защит, а тут борроу чекер. Если вы не разбираетесь, не надо комментировать с умным видом про "пойманных на маркетинг"
>Си - вообще не даёт никаких защит, а тут борроу чекер.не даёт из коробки, это как gdb не часть vim.
но если надо есть frama-c, а если это слишком много, то есть статический анализатор или просто более сильные флаги компилятора.
Все защиты есть, просто это не IDE поставить с плагинами и делать вид, что это и есть профессионализм.
У товарища Дейкстры IDE не было, но профессионалом он был.p.s. C язык высокого уровня, вот в ассемблере защит и правда нет.
>За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости.Кто тут говорил, что Раст безопасен?
Раст небезопасен там есть unsafe
В данном случае следовало бы сказать, что не Rust, а некоторые библиотечные функции.
На безопасном языке невозможно написать небезопасную библиотеку. Головой поработай чутка.
Да, можно. Но это будет осознанный поступок в отличие от кода на Си, где вы даже не заметите, как на очередную мину наступите, а потом, когда это выстрелит в проде, потратите ещё кучу времени на поиск бага.
Тонко ;)
Здесь более подходит слово "глупо".
> На безопасном языке невозможно написать небезопасную библиотеку.Неужели? Возьмём самый безопасный язык из самых популярных - Питон. Скажете, что нельзя на нём файлы поудалять случайно? Правильный ответ - можно. Но как же так? Он же безопасный?
Вот и поработайте головой, прежде, чем писать подобные глуповатые утверждения.
Я говорил. Но всегда уточнял, что безопасность касается только типовых ошибок работы с памятью, а не вобще всех на свете, от которых может спасти только формальная верификация, как здесь уже отмечали. Однако эта верификация - процесс медленный, очень дорогой, и поэтому далеко не всегда целесообразный.
Go тоже безопасность от типовых ошибок.
Ну вот зачем вы продолжаете из сообщения в сообщение демонстрировать дремучее невежество? Код на Go будет более тормознутым и непредсказуемым в плане производительности по сравнению с кодом на Rust. Потому что в Go используется сборщик мусора. А в Rust его нет.
А толку, если у язычка нет спецификации? Он небезопасен by design, парадоксально, но даже Си безопаснее, потому что минимальная работа по стандартизации проведена.
Это вы про тот стандарт, которым подтираются (-fno-strict-aliasing) чтобы собрать ядро linux?
Я сам терпеть не могу Си, но, в отличие от Rust, он имеет несколько относительно взаимозаменяемых реализаций.
Если что-то плохое случится с разработкой компилятора Rust (например, крупный слом обратной совместимости), это затронет всех разработчиков на Rust.
> Я сам терпеть не могу Си, но, в отличие от Rust, он имеет несколько относительно взаимозаменяемых реализаций.У раста тоже есть несколько компиляторов.
> Если что-то плохое случится с разработкой компилятора Rust (например, крупный слом обратной совместимости), это затронет всех разработчиков на Rust.
Это как?
У них есть Edition в которых как раз фиксируются изменения ломающие совместимость.
Т.е можно указать Edition-2018 и спокойно писать.А если завтра в С29 сломают? То что будет?
Точно так же зафиксируется версия языка в проекте и всё, проблем быть не должно.
>Я сам терпеть не могу Си, но, в отличие от Rust, он имеет несколько относительно взаимозаменяемых реализаций.И каких же? А то целые новости "$проект теперь можно собирать llvm"!
>Если что-то плохое случится с разработкой компилятора Rust (например, крупный слом обратной совместимости), это затронет всех разработчиков на Rust.А что же будет в си в этом случае? Опять нельзя будет проект собирать любым компилятором?
> несколько относительно взаимозаменяемых реализаций.Ну есть. А толку?
Вот потратили N человеколет на то, чтобы ядро компилировалось еще хотя бы чем-то кроме gcc. Отличный пример взаимозаменяемости. А напр. хромиум достаточно долго не компилился gcc10, пока это тоже не исправили.> Если что-то плохое случится с разработкой компилятора Rust
то все просто будут компилять последним имеющимся.
Точно также как если что-то произойдет с разработкой gcc, напр. они будут тянуть с принятием новых стандартов.
Вы не побежите менять компилятор.> крупный слом обратной совместимости
У раста как раз с обратной совместимостью все лучше чем у си и с++.
> А толку, если у язычка нет спецификации? Он небезопасен by design, парадоксально,
> но даже Си безопаснее, потому что минимальная работа по стандартизации проведена.Это да, поэтому минимальный код для сложения знаковых чисел _по_стандарту_:
#include <limits.h>
void f(signed int si_a, signed int si_b) {
signed int sum;
if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
/* Handle error */
} else {
sum = si_a + si_b;
}
/* ... */
}
красота, че!
Как это оптимизировать чтобы код выполнялся за минимальное количество тактов? Да никак код или быстрый или безопасный или рыжая морда опять звездит.
> код или быстрый или безопасный или ...поведение просто определеной и у тебя не будет UB.
А просто будет two's complement wrapping.Получается и быстро, и безопасно, и главное предсказуемо.
Поведение едино для языка, а не приколочено к платформе, компилятору, флагам, фазе луны...
> Как это оптимизировать чтобы код выполнялся за минимальное количество тактов?
> Да никак код или быстрый или безопасный или рыжая морда опять звездит.Ну, с высоты опеннетных, совсем не палящихся кекспердов-теоретиков все может быть.
А так-то:
if (__builtin_sadd_overflow(si_a, si_b, &sum))
и будет из всех проверок на (не очень экзотических) платформах условный JO/BVS, вместо вон того вон.
Работает в шланге, gcc и icc - ну это кому шашечки.
С помощью зависимых типов, очевидно же. Но сишники же про типизацию не слышали, у них везде void*
На уровне ассемблера и регистров процессора, сложение двух 32-битовых регистров со значениями 0x7FFFFFFF тоже приведёт к переполнению. Вот только процессор об этом явно скажет флагом, а ЯВУ этот факт от программиста сознательно прячут.
Вот и рождаются такие монстры "сложения по стандарту"
> но даже Си безопаснееСи дыряв прям по его убогому недостандарту. Потому что назвать, да и еще и хвастаться, стандартом то, в чем 193 UB - это просто плевок в лицо всем стандартизаторам
gist.github.com/Earnestly/7c903f481ff9d29a3dd1При этом в safe расте нет UB. При том что у него нет "коммитетского" стандарта, а набор RFC.
rust-lang.github.io/rfcs/В unsafe есть немного UB, из-за необходимости взамодействия с другими языками, в том числе и с мерзопакостной. doc.rust-lang.org/reference/behavior-considered-undefined.html
И это не учитывая разное поведение разных компиляторов и даже версий одного компилятора.
Ну и где дыряшка безопаснее?
> При этом в safe расте нет UB.в safe C тоже
>> При этом в safe расте нет UB.
> в safe C тожеА что это за "safe C"?
Я в стандарте такого не читал.
Оно вообще релизнулось?Если нет стандарта, то зачем брать какое-то васяноподелие - у меня уже такое есть - раст называется.
> Я в стандарте такого не читал.можешь курсы пройти
> Если нет стандарта, то зачем брать какое-то васяноподелие - у меня уже такое есть - раст называется.
напиши что-нибуть на расте безопасное низкоуровневое потом приходи, а такой раст как у тебя есть у любого школьника в фантазиях, толку только никакого
>> Я в стандарте такого не читал.
> можешь курсы пройти
> https://ldra.comКурсы мисры? Спасибо за совет)
Насколько я помню все "рекомендации" не являются обязательными к исполнению.Я открыл ISO/IEC 9899:2011 и там нет ничего про "safe c"
> напиши что-нибуть на расте безопасное низкоуровневое потом приходи, а такой раст как у тебя есть у любого школьника в фантазиях, толку только никакого
Я на расте не пишу, пусть другие делают.
И кстати у них получается - видеодрайвер для M это достаточно низкоуровнево?
Или прошивки для вольво или рено?
> видеодрайвер для M это достаточно низкоуровнево?да, но когда напишут ещё безопасно - приходи
https://www.khronos.org/vulkansc
> Или прошивки для вольво или рено?
не в курсе что там но машинки их не особо ценятся на рынке
>> видеодрайвер для M это достаточно низкоуровнево?
> да, но когда напишут ещё безопасно - приходи
> https://www.khronos.org/vulkanscЕсли чуваков устраивает МИСРА без ISO стандарта, то ок.
Если кому-то захочится большего - будут переписывать на другой язык или диалект.
Сапожник то без сапог!
Предполагаю, что истинной целью проекта Rust является отвлечение ресурсов потенциальных конкурентов на изучение бесперспективного проекта и бессмысленные дискуссии. Это известные действия, и в науке даже имеют специальный термин - "троянское обучение".
Да методичку по саботажу никто пока что не менял и не исправлял.
> Да методичку по саботажу никто пока что не менял и не исправлял.А откуда у вас информация, что методичку не поменяли?
Палитесь, товарищ!
Вы не понимаете, это всё - борьба с безработицей. Так же как и крипта.
У вас предполагалка сломалась. Раст восстребован: Гугл, Амазон, Дискорд, Дропбокс, Клаудфлэр - все эти фирмы используют Раст, а скоро ожидается и в ядре Линукса (хотя это и находит определённое сопротивление некоторых дедов, которые уже просто не могут).Бесмыссленными дискуссии бывают только тогда, когда прилетает очередное "чудо-дитя", которое ни строчки документации не прочитало, и тут же начинает высказывать свои "ценные мнения", не владея предметной областью и с весьма ограниченным кругозором.
Критиковать легко. А что вы лично предлагаете?
А предлагаю следующее. Всем притормозить инновации и начать переписывать имеющиеся проекты на Раст. Пусть вы потратите на это десять лет и разгоните опытных программистов, которые не хотят изучать это фуфло. Потому что
> Гугл, Амазон, Дискорд, Дропбокс, Клаудфлэр - все эти фирмы используют Раст
> А предлагаю следующее. Всем притормозить инновацииПод инноовациями понимается очередная порция CVE-шек, которые потом не один десяток лет будет вылавливать так называемое "сообщество"?
> и начать переписывать имеющиеся проекты на Раст.
Имеющиеся можно не трогать, если они не критичны к стабильной работе. А те, которым такая стабильность критична, или это полностью новые проекты - почему бы и нет.
> Пусть вы потратите на это десять лет и разгоните опытных программистов, которые не хотят изучать это фуфло.
Если программисты действительно опытные, для них не составит труда изучить за примерно 30-50 часов язык, который гарантирует более высокую стабильность работы. А если это по случаю примкнувшие Васяны, чьи когнитивные возможности оставляют желать лучшего, то от таких лучше избавляться.
> Гугл, Амазон, Дискорд, Дропбокс, Клаудфлэр - все эти фирмы используют Раст
> Потому что
>> Гугл, Амазон, Дискорд, Дропбокс, Клаудфлэр - все эти фирмы используют РастЧто плохого в том, что перенимать положительный опыт у лидеров в сфере разработке ПО?
Предлагаю использовать Rust в новых проектах вместо морально устаревшего C, например. Ну и вообще там, где требуется высокая производительность.
Прости, коллеги, я тут немного сам с собой спорю. Это не потому что не с кем, а потому что с умными людьми приятно и поспорить.
Самомнение-с зашкаливает
>в 7500 встречаются блоки кода, выполняемые в контексте "unsafe". За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости.Такая вот безопасТная безопасность ;)
Я правильно понимаю, обнаружив уязвимость в единственой библиотечке RUST, я поимею доступ ко всему, что создано на RUST
Это должна быть как минимум популярная библиотека. А чем популярнее библиотека тем более умные люди там пишут. И вряд ли будут косячить в блоках unsafe. Нали блоки unsafe им в принципе надоСамые большие косяки в unsafe делают мамкины программисты. У которых это возможно это их первый язык. И они почему-то решили побаловаться с unsafe. Но их крэйты никому не нужны
> А чем популярнее библиотека тем более умные люди там пишутСильное утверждение, проверять я ее конечно не буду
Да, как и в библиотеке, написанной на другом языке, ведь ты попал в Linux.
Стесняюсь спросить, вы вообще программировали когда-нибудь в своей жизни? Потому что судя по задаваемому вопросу, вы или очень далеки от этой темы, или беспросветно глупы.
В каждой бочке затычка. Люди пишут своё мнение. У тебя чтоли разрешение спрашивать?
Он знает про ядро. Опытный собеседник.
Про существование такой штуки, как ядро.
Подобные вопросы выглядят как очень и очень тупой троллинг. Мне НЕ нравится такой стиль общения. И я по этому поводу написал своё мнение. Вы, как будто, не против, чтобы каждый высказывал своё мнение, да?
Нет, поскольку не все программы используют эту библиотеку, кроме того, у библиотек разные версии
почему было изначально вместо rust'а с unsafe не сделать блок safe в уже всем известных сях?
> почему было изначально вместо rust'а с unsafe не сделать блок safe в уже всем известных сях?потому что:
1. Последние лет пять (а может и дольше) я слышал только то, что дополнительные проверки не нужны. это было под разными соусами: начиная от "30 лет работало, зачем что-то менять" да "Настоящий программист таких глупых ошибок не делает".
Т.е в момент когда раст начинали делать, о такой задаче вообще никто не думал.2. Скорее всего это сломает обратную совместимость - а на нее что СИшники, что плюсовики моляться.
(вот например Fil-C opennet.ru/opennews/art.shtml?num=62241 - замедление 1.5-5 раз, GC и нарушение ABI).3. Скорее всего это будут принимать в стандарт лет 10 - а это вторая священная корова, для любителей небезопасных языков.
Некоторые пишут честно, как например автор TrapC (opennet.ru/opennews/art.shtml?num=62224) называющий свое творение "safe fork of C".
Но проект пока весьма сырой и имеет ФАТАЛЬНЫЙ НЕДОСТАТОК - "TrapC будет совместим с Си, что позволит комбинировать в одном приложении код на TrapC и чистом Си, но для кода Си не будет обеспечиваться безопасность работы с памятью"
Т.е все равно переписывать.
>3. Скорее всего это будут принимать в стандарт лет 10 - а это вторая священная корова, для любителей небезопасных языков.Вот в этот -std=gnu2xyz сами разработчики компилятора это могут добавить, не дожидаясь официального стандарта.
У сишников было лет пятьдесят, и никаких подвижек в этом направлении нет. Так ещё лет двадцать пройдёт, и ничего не изменится
Вообще люди, работающие с Си, давно для этого по-максимуму используют встроенные проверки в компилятор, которых с каждым годом становится всё больше (и обязательно собирают с -Werror, чтобы посильнее по рукам било). Используют статические анализаторы, используют определённый code style и делают code review не для галочки. И у них прекрасно получается писать вполне себе safe код. Поэтому проблема в Си чисто организационная - кто-то хочет писать грамотный и корректный код, а кто-то хочет поскорее выкатить версию.
Мда. Вместо обсуждения реальных проблем языка Rust и возможных способов их преодоления люди склонны заниматься всяким словоблудием и тупым троллингом.Хотя с другой стороны. Чтобы знать о реальных проблемах этого языка программирования, надо же вначале хоть что-то прочитать о нём. А это уже гораздо сложнее для когнитивных возможностей некоторых высказывающихся.
В итоге, вместо полезного обмена опытом получаем перепалку на тему "Rust не нужен, потому что я его не осилил".
Беда, печаль.
> Чтобы знать о реальных проблемах этого языка программирования, надо же вначале хоть что-то прочитать о нём. А это уже гораздо сложнее для когнитивных возможностей некоторых высказывающихся. Я тоже программировать как-то не сильно. Но
> заниматься всяким словоблудием и тупым троллингомлюблю.
И это подтверждает мою т.з.
Домыслы. На другое когнитивных способностей не хватает.