Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от opennews (??), 24-Ноя-24, 11:53
Компания Amazon и организация Rust Foundation представили инициативу, нацеленную на повышение безопасности стандартной библиотеки языка Rust. Целью заявлена проверка надёжности и безопасности функций, в которых используется ключевое слово "unsafe", допускающее операции, небезопасно работающие с памятью, такие как разыменование указателей, изменение статических переменных и обращение к внешним библиотекам на С/C++. Отмечается, что в настоящее время стандартная библиотека Rust насчитывает около 35 тысяч функций, из которых в 7500 встречаются блоки кода, выполняемые в контексте "unsafe". За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62286
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Инициатива по верификации стандартной библиотеки Rust"	+11 +/–
Сообщение от Аноним (1), 24-Ноя-24, 11:53
> При этом за последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости. Как же так? Ведь Rust должен был обернуть небезопасные части в загончик unsafe, чтобы как раз не было такого. Выходит, не помогло? А верифицировать любой код можно, не только Rust.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Инициатива по верификации стандартной библиотеки Rust"	+8 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 11:57
	> Ведь Rust должен был обернуть небезопасные части в загончик unsafe, чтобы как раз не было такого. Так они это и сделали. Поэтому проблемы если возникают, то именно unsafe блоках. Не считая логических багов. От них только формальная верификация и спасет. > Выходит, не помогло? Наоборот, помогло. Посмотри сколько функций и в скольки есть unsafe. > А верифицировать любой код можно, не только Rust. Можно. Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках. А это почти в 5 раз меньше работы.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Инициатива по верификации стандартной библиотеки Rust"	+5 +/–
	Сообщение от Аноним (8), 24-Ноя-24, 12:23
	>А это почти в 5 раз меньше работы. А вот это вряд ли, потому что каждое включение unsafe на Rust в 5 раз сложнее проверять, чем в других языках.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
	Сообщение от Facemaker (?), 24-Ноя-24, 12:24
	>каждое включение unsafe на Rust в 5 раз сложнее проверять, чем в других языках Как вычислялась эта метрика?
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Инициатива по верификации стандартной библиотеки Rust"	+13 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 12:37
	> Как вычислялась эта метрика? Методика 'Пальцем в небо' сертифицированного сотрудника 'НИИ Кекспертизы и вбросов' им. Опеннета. Все утверждения истинны на 146%! Я бы спросил в чем отличие unsafe rust от обычной сишки, но смысла нет - все равно ответа не получим))
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (35), 24-Ноя-24, 14:23
	В чем отличие safe rust от обычной сишки?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:24
	Больше лишних проверок, которые в си пришлось бы писать руками на каждый чих.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:13
	Гм. Странное у вас определение понятия "лишний". Вот Гугл, Майкрософт и прочие компании, применяющие Rust, считают, что эти проверки совсем не лишние. А эксперт с Опеннета - что лишние. Кому верить?
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аномсис (?), 25-Ноя-24, 02:20
	Как я понял, даже unsafe в rust более безопасен, чем Си. Потому что в rust даже в блоке unsafe производятся некоторые проверки
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	21. "Инициатива по верификации стандартной библиотеки Rust"	+3 +/–
	Сообщение от erthink_ (?), 24-Ноя-24, 13:15
	Нет. Ровно наоборот. Даже если иметь кривые руки, плохую голову и что-то натянуть против раста, то верификация unsafe в его собственных библиотеках потребует в разы меньше усилий чем верификация сишных библиотек со сравнимым функционалом. В среднем по больнице, unsafe-код в Rust более регулярен и проще (менее комплексный) чем подобный в сишных библиотеках. Есть и обратный эффект, в unsafe-функциях концентрация странностей/мутностей больше чем в средней glibc. Но это только потому, что в rust есть возможность и стремление отделять мух от котлет, а в glibc любые unsafe операции могут быть в любом месте (в самом безобидном и неожиданном). Конечно, можно найти зубодробительные unsafe-сценарии, но тогда и сравнивать их надо с аналогичными сишными случаями.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	51. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:26
	Язык си необоснованно сложнее и найти там что-то ещё сложнее вывод очевиден. Хотя вывод понятен по отсутствию софта написанного на раст. Особенно в областях где хваленая работа с памятью могла бы иметь место.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от erthink_ (?), 24-Ноя-24, 16:30
	> Язык си необоснованно сложнее и найти там что-то ещё сложнее вывод очевиден. Язык Си сильно проще, а С++ отягощен поддержкой обратной совместимости (с позволением всего unsafe что можно в Cи). > Хотя вывод понятен по отсутствию софта написанного на раст. Особенно в > областях где хваленая работа с памятью могла бы иметь место. Так ведь именно активно используется, даже не взирая не упомянутые выше баги. И переписывается на Rust достаточном много, там где либо высоки риски и в совокупности есть целесообразность для бизнеса, либо где что-то кому-то интересно. Другое дело, что в условном debian этого не видно, ибо 90% пакетов появились до раста и вся экосистема "сишная".
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:51
	Может уже пора перестать переписывать и написать что-то новое на самом расте?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (116), 24-Ноя-24, 17:59
	Лол. Кто ты вообще такой чтобы что-то, кому-то указывать? Особенно разрабам которые свои проекты на Rust перекатывают.Да и нового софта на Rust уже вагон, и игровые движки и редакторы кода, и целая DE с прикладнухой. С разморозкой!
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Bottle (?), 24-Ноя-24, 19:56
	There 5 games and 50 game engines written in Rust, как говорится.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:16
	Такое всегда бывает. Сначала вызревает какой-то движок (несколько движков). Потом появляются игры на них. На Плюсах только потому больше игр, что он намного старше Rust. То же можно сказать и про другие языки, на которых обычно пишут игры.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Я (??), 24-Ноя-24, 22:25
	так так и делают. просто нового кода всегда меньше чем уже написанного
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	126. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (126), 24-Ноя-24, 19:35
	unsafe это только индикативность для менеджеров или реализует безопасные механизмы (замыкание, контекст, виртуальность)?
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	13. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (13), 24-Ноя-24, 12:39
	> Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках. в другом языке есть формально верифицированный компилятор https://compcert.org а у раста пока что даже не формализовали ситему типов https://blog.rust-lang.org/2023/01/20/types-announcement.html
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	28. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от erthink_ (?), 24-Ноя-24, 13:56
	> в другом языке есть формально верифицированный компилятор > https://compcert.org Нисколько не хочу принизить ценность проекта и достигнутые там результаты, но всё-таки нужно слегка критично читать написанное с осознанием всего комплекса проблем/задач. Формальная/математическая верификация покрывает часть функционала, т.е. "не всё". При этом возникает некая проблема/задача верификации "самого верификатора", т.е. доказательства что сформированного списка свойств достаточно для "верифицированного компилятора". Например, предположим что у вас есть "верифицированный компилятор". В нём могут быть баги ? - если "нет, багов быть не может", то упомянутый компилятор нельзя назвать верифицированным. - если "да, баги могут быть", то верификация перестаёт что-либо гарантировать на практике. Поэтому все подобные верификации всегда с массой уточнений и оговорок "тут рыбу заворачивали, сюда не смотрим" и "если остальное работает верно". Соответственно, отсутствие "формализированной системы типов" им не только не мешает, но и может помогать (сокращать поверхность).
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (13), 24-Ноя-24, 14:54
	> Поэтому все подобные верификации всегда с массой уточнений и оговорок там написано вполне ясно > 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. > Соответственно, отсутствие "формализированной системы типов" им не только не мешает, но и может помогать (сокращать поверхность). без формального описания не может быть никакой верификации, как это может "помогать" ?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (44), 24-Ноя-24, 15:11
	> без формального описания не может быть никакой верификации это называется спецификация, в этой же спеке определяется понятие "баг".
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (13), 24-Ноя-24, 15:22
	> это называется спецификация, в этой же спеке определяется понятие "баг" есть один компилятор и никто точно не знает как он работает, только догадываются. Сомневаюсь что кто-то в своём уме пишет на этом доверенный код.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (44), 24-Ноя-24, 16:10
	> есть один компилятор и никто точно не знает как он работает, только догадываются. На то и спека, где это все описано, и есть механизм верификации и валидации, который позволяет проверить с тем, что написано в спеке. > Сомневаюсь что кто-то в своём уме пишет на этом доверенный код. У кода, формально верифицируют его корректность. Вы понимаете, что такое корректность?
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (13), 24-Ноя-24, 16:23
	> У кода, формально верифицируют его корректность. Вы понимаете, что такое корректность? есть код на языке программирования и есть код исполняемый процессором, вы разницу вообще понимаете ?
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (44), 24-Ноя-24, 19:46
	> есть код на языке программирования и есть код исполняемый процессором, вы разницу вообще понимаете ? а какая разница, если и то и другое надо верифицировать? Цель верификации одна - """ формальное доказательство соответствия или несоответствия предмета верификации его формальному описанию. Предметом выступают алгоритмы, программы и другие доказательства. """
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от erthink_ (?), 24-Ноя-24, 15:56
	>> без формального описания не может быть никакой верификации > это называется спецификация, в этой же спеке определяется понятие "баг". Не важно как называется, но суть в определении рамок/границ что верифицируется, а что оставляется за скобками. И тут всё правильно, ибо по-другому не возможно. Но нужно понимать что именно верифицировано и в "каких терминах", так как в конечном счете нет большой разницы чем будет вызвана проблема -- багом компилятора, не-верифицированностью каких-то его частей, либо изъяном в правилах/целях/критериях/ограничениях верификации. Поэтому читая "верифицированный компилятор" всегда хочется понять что имели в виду: - конкретный exe-шник. - набор исходников или какое-то их подмножество. - представление кода и его преобразования описанные в некой формальной системе, для которых доказана их корректность. - формальная система для описания представления кода и его преобразований, которая позволяет выполнить доказательства корректности.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	81. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (44), 24-Ноя-24, 16:18
	> Не важно как называется, но суть в определении рамок/границ что верифицируется, а что оставляется за скобками. Ну и как продолжать дискуссию, если нет понимания для чего вообще нужно это все, если изначально не важно как это все называть. > Поэтому читая "верифицированный компилятор" всегда хочется понять что имели в виду: Читая где? вот откройте страницу этого компилятора и прочитайте, что там специфицировали, что верифицировали и валидировали, и как это все вам повторить в домашних условиях. Хотя сначала нужно открыть и прочесть теорию данной области (формальной верификации). И все вопросы вида "что имели в виду" сразу отпадут. > багом компилятора Ну дайте мне строгое определение этого термина. Правильно ведь, без толку его мне щас давать?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Я (??), 25-Ноя-24, 00:15
	вера+фикция = верификация.. на том и держится
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	54. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от erthink_ (?), 24-Ноя-24, 15:31
	> без формального описания не может быть никакой верификации, как это может "помогать" > ? Ту там же символьные вычисления и местами абстрактная алгебра. Например, можно верифицировать что "компилятор" не нарушает систему типов, без полной формализации и/или верификации самой системы типов. Конечно, такой "компилятор" может быть не в состоянии генерировать исполнимый код. Либо всё-таки уметь это, но уже с подмешиванием не-верифицированного функционала и/или не-верифицированной системы типов. А еще может выясниться, что конкретная система типов может не-покрываться/требовать-большего, чем умеет верифицированная часть компилятора, и/или требовать снятия части ограничений/формулировок введенных для возможности верификации, и т.п. -- Собственно, хотел обратить внимание, что есть "рамки верификации" и почти всегда практическое применение никак в них не помещается.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	128. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (44), 24-Ноя-24, 19:50
	> Собственно, хотел обратить внимание, что есть "рамки верификации" и почти всегда практическое применение никак в них не помещается. что такое "практическое применение"? Что такое "рамки верификации" когда есть строгое определение "предмета верификации"?
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (93), 24-Ноя-24, 16:42
	в расте есть MIRI
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	16. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 12:52
	> Поэтому проблемы если возникают, то именно unsafe блоках. https://github.com/Speykious/cve-rs - в фантазиях. > А это почти в 5 раз меньше работы. Нет, это столько же работы, точнее даже больше. Сейф раст ничего не гарантирует.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	33. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 14:21
	Вот эпичный тред, где люди в течение недели(!) пытались заставить это работать 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
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (35), 24-Ноя-24, 14:30
	Не знаю, что ты там компилируешь? $ cargo install cve-rs $ ~/.cargo/bin/cve-rs segfault Segmentation fault (core dumped)
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Инициатива по верификации стандартной библиотеки Rust"	+3 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 15:12
	> Нет, это столько же работы, точнее даже больше. Сейф раст ничего не > гарантирует. Но только в фантазиях опеннетных кекспертов-военов супротив раста, не ходящих по своим же ссылкам. 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. Воены-кексперты, что с лицом?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	46. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (35), 24-Ноя-24, 15:18
	>> https://github.com/rust-lang/rust/issues/25860 opened on May 28, 2015 >Воены-кексперты, что с лицом? У меня всё прекрасно, а у вас что с лицом уже почти 10 лет?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 15:33
	> Сейф раст ничего не гарантирует. ... > opened on May 28, 2015 >>Воены-кексперты, что с лицом? > У меня всё прекрасно, а у вас что с лицом уже почти Какое ловкое переобувание в прыжке, однако ...
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (35), 24-Ноя-24, 15:44
	А ты забавный. Тебе показывают, что язык дырявый. Ты даешь ссылку, что дыра существует 10 лет. Причем в обсуждении дыры прямо пишут, что у раста проблемы тайпчекером и системой типов. 10 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:53
	Не язык, а компилятор. Да, нашли в нём недоработку. И?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (35), 24-Ноя-24, 16:06
	> Не язык, а компилятор. На данном этапе развития rust язык и референсный компилятор неотделимы. И повторюсь, пишут что есть проблемы с системой типов - это именно про язык. Исправят только в "следующем поколоении".
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:19
	Даже на данном этапе язык и компилятор - это разные вещи. Поскольку одно есть, условно говоря, спецификация (набор RFC в случае Rust), а другое - её имплементация. Про систему типов хотелось бы больше подробностей.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:25
	Про систему типов вы вот эту ссылку имели ввиду, видимо? https://blog.rust-lang.org/2023/01/20/types-announcement.html Дык это такие же "проблемы", как и в любом другом развивающемся языке программирования.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	80. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 16:14
	>> 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" ЯПы либо остаются маргинальными академическими поделками, на которых никто не пишет, либо строчка кода, для тех же критических систем, обходится в очень нехилую сумму денег, плюс минимум еще столько же за верификацию "взаимодействия" этого кода с реальностю.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	91. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (35), 24-Ноя-24, 16:35
	> проигнорировал ответ автора cvs-rs, проигнорировал сложность абуза этого бага Ничего я не игнорировал. Вам дали ссылку на конкретый баг с полным описанием, как этот баг экплуатируется. "Сложность" и "невозможность" находятся по разную сторону. Евангелистам не надо было распинаться про "невозможность", не тыкали бы этим проектом в лицо. > Хотя открою тайну: полностью "sound" ЯПы Я хорошо знаю сложность (NP) верификации алгоритмов, в том числе про сложность работы с памятью (NP). Поэтому резко против евангелистов rust с "безопасной работой с памятью". На данном этапе разития математики, науки и техники (формальную) корректность можно проверить только у небольшой программы. Жду "следующего поколения"
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 17:24
	>> проигнорировал ответ автора cvs-rs, проигнорировал сложность абуза этого бага > Ничего я не игнорировал. Вам дали ссылку на конкретый баг с полным > описанием, как этот баг экплуатируется. Какая занимательная реальность, в моей - это описание дал я сам, а воены супротив раста выдали лишь невнятное "ничего не гарантирует, вот!" ... > Я хорошо знаю сложность (NP) верификации алгоритмов, в том числе про сложность > работы с памятью (NP). Поэтому резко против евангелистов rust с "безопасной > работой с памятью". На данном этапе разития математики, науки и техники > (формальную) корректность можно проверить только у небольшой программы. Сложность NP решается ограничением на лишь определенное подмножество операций (ну вон, см. трудности реализации двусвязного списка в расте) и "ручной проверкой" всего остального. Это позволяет задействовать мощности компьюктеров для проверки хотя бы части кода, вместо заката солнца ручками. Внезапно, да? А то на идрисах, агдах и коках чей-то не видно программ общего-системного назначения ...
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 19:12
	> А то на идрисах, агдах и коках чей-то не видно программ общего-системного назначения ... Не идрис, но хаскель - вон даже ОС запилили. programatica.cs.pdx.edu/House/ Выглядит она конечно как привет из 90х, но ГУЙ можно и поменять. Тут вопрос в другом - сложность. Да и найти программеров на хаскель сложно, там нужны мозги чтобы не погрязнуть в монадах и функторах. А на СИ или PHP можно научить лабать даже камаку - поэтому они и распространенные.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:35
	ОС можно запилить на абсолютно любом языке программирования (полным по Тюрингу). Скорее всего, предыдущий высказывающийся имел ввиду эффективную с точки зрения использования машинных ресурсов ОС, а не просто ОС-прототип. Где-то попадались статьи, что на языках, поддерживающих исключительно функциональную парадигму программирования такое практически невозможно осуществить, ввиду сложности оптимальной реализации некоторых абстракций. Подробности, увы, уже не помню, статья попадалась лет 10 назад примерно.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:22
	Только для целевой атаки достаточно одной уязвимости. Подумай об этом. И про ложку дегтя в бочке меда. Не имеет смысла размер бочки если любое количество дегтя делает даже самую безопасТную бочку неюзабельной. Можно просто сэкономить на бочке.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	60. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 15:37
	> И про ложку дегтя в бочке меда. Не имеет смысла размер бочки если > любое количество дегтя делает даже самую безопасТную бочку неюзабельной. Можно просто > сэкономить на бочке. О, Воены Супротив Раста подтянули "тяжелую артиллерию" в виде натягиваемых на глобус аналогий. Надеюсь, Воены пилят только ручной пилой (и используют такую же продукцию), а то ведь электро/бензопилу и всякие индустриальные лесопилки легко отыметь простым ломом, что делает их с точки зрения-"логики" Военов неюзабильными ...
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:27
	Нет никаких военов. Есть только люди со здравым смыслом и это не ты. Кому безопасно есть питон, го, хаскель, джаваскрипт. Руст от них ничем в лучшую сторону не отличается.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от laindono (ok), 24-Ноя-24, 18:38
	Отличается производительностью выполняемого кода в той же когорте, что и C/C++. Раньше выбор стоял между крестиками и питоном (условно) и выбор состоял в безопасности против производительности. Теперь выбор между растом и условным питоном. При этом выбор между скоростью написания кода и производительностью. Со временем плюсы станут коболом. Куча легаси кода, который никто особо не хочет трогать кроме старичья.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (77), 24-Ноя-24, 16:03
	>Поэтому проблемы если возникают, то именно unsafe блоках. А Rustonomicon говорит строго обратное, что unsafe - нелокален, и что от него проблемы могут возникнуть вообще где угодно.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	146. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 22:10
	> А Rustonomicon говорит строго обратное, что unsafe - нелокален, > и что от него проблемы могут возникнуть вообще где угодно. Нет. Проблемы находятся именно в unsafe блоках. А вот последствия этих проблем таки да не локальны и могут проявится везде. Как следствие при напр. неясном segfault нужно просмотреть только unsafe code, чтобы найти проблему, а не всю кодовую базу.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от fuggy (ok), 25-Ноя-24, 02:14
	Риторический вопрос, сосед интересуется. Почему бы убрать unsafe в некоторых случаях чтобы вместо 7500 было бы 3500 unsafe функций. То есть переписать частично на safe rust, так и верифицировать меньше придётся. Раз оно что-то там не сходится, то значит не хватает абстракций. А то выходит если что-то не получается без unsafe, то просто используем его затычку и делаем чёрную магию.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	196. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от ptr (ok), 25-Ноя-24, 10:50
	> Поэтому проблемы если возникают, то именно unsafe блоках. Проблемы возникают на любом уровне, так как unsafe лишь косвенно влияет на них. Классический пример - использование MaybeUninit. Проблемы возникают при ошибках в его использовании, а вовсе не в самом unsafe блоке. > Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках. По вышеописанным причинам, верифицировать потребуется всё равно всю библиотеку. Даже контроль за входными параметрами осуществляется совсем не в unsafe блоке. > А это почти в 5 раз меньше работы. В той же glibc функций, в которых потенциально возможны угрозы, тоже не порядка 20% процентов. Так что тут паритет.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	197. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от ptr (ok), 25-Ноя-24, 10:55
	> Поэтому проблемы если возникают, то именно unsafe блоках. Проблемы возникают на любом уровне, так как unsafe лишь косвенно влияет на них. Классический пример - использование MaybeUninit. Проблемы возникают при ошибках в его использовании, а вовсе не в самом unsafe блоке. > Но в расте тебе нужно будет верифицировать 7.5к функция, а не 35 тысяч как в других языках. По вышеописанным причинам, верифицировать потребуется всё равно всю библиотеку. Даже контроль за входными параметрами осуществляется совсем не в unsafe блоке. > А это почти в 5 раз меньше работы. В той же glibc функций, в которых потенциально возможны угрозы, тоже не порядка 20% процентов. Так что тут паритет.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	6. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (6), 24-Ноя-24, 12:03
	Нет ничего иделаьного! А результат всяко лучше по сравнению с С/C++.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	90. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (90), 24-Ноя-24, 16:35
	Если на стройке носить 10 касок подряд, то будет в 10 раз безопаснее! Но почему-то в реальности так никто не делает.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от proninyaroslav (ok), 24-Ноя-24, 12:04
	А теперь представим что unsafe нет, и нужно перелопатить 35к функций, вместо 7500 если бы unsafe был.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	15. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 12:48
	Там и так нужно перелопатить 35к, уб в расте есть везде. Не говоря о том, что многие из этих 35к - хэлворды.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от proninyaroslav (ok), 24-Ноя-24, 12:59
	UB в расте не может быть за пределами unsafe блока. Это гарантированно. Все остальное он конечно не гарантирует, например утечки памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 13:23
	Эти гарантии уже умножены на ноль. Кидал ссылку ниже.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от proninyaroslav (ok), 24-Ноя-24, 15:20
	Семантика языка, которая гарантирует безопасность, это всего лишь описание. Но конечно многое зависит от компилятора и его уязвимостей которые всегда есть. И этот проект по сути их демонстрирует.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:33
	Он демонстрирует что в расте нет никакой необходимости. Дешевле писать на нормальных языках. Сейф на питоне, ансейф быстрый код на с++ как модули для питона. Все экономия 1000%
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (90), 24-Ноя-24, 16:36
	Питон на реальных задачах в сотни раз медленее Си. Лучше уж Java или C#.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:49
	Куда ты так торопишься задача ты моя? Так можно и успеть.
	Ответить | Правка | Наверх | Cообщить модератору

	120. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 18:08
	> Он демонстрирует что в расте нет никакой необходимости Наверное, поэтому правительство штатов приказало предоставить план отказа от C/C++ к 2026 году.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	34. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (126), 24-Ноя-24, 14:21
	>Это гарантированно. Кем или чем?
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	55. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:32
	Почему нельзя сразу написать безопасно. Если есть ансейф то язык уже небезопасен.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	152. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Минона (ok), 24-Ноя-24, 23:10
	Можно, но это либо дорого либо неэффективно.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (180), 25-Ноя-24, 07:55
	Надо теперь всё с Rust переписать на SPARK, чтобы было надёжно и верифицируемо.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

5. "Инициатива по верификации стандартной библиотеки Rust"	+4 +/–
Сообщение от ijuij (?), 24-Ноя-24, 12:02
Unsafe был введён более пяти лет назад (https://github.com/rust-lang/rust/commit/10855a36b53d33aa2e4...), и за это время люди успели использовать этот ключевое слово в множестве проектов. Однако только сейчас они начали заниматься его верификацией. Ну что ж, подход к безопасности действительно "на высшем уровне".
Ответить | Правка | Наверх | Cообщить модератору

	31. "Инициатива по верификации стандартной библиотеки Rust"	+3 +/–
	Сообщение от Аноним (126), 24-Ноя-24, 14:15
	Верифицируют библиотеку, а не unsafe.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:36
	Но ведь адепты говорили что факт написания ансейфа будет помогать программисту сильнее концентрироваться на ошибках в коде, а оказывается не помогает. И хакер все равно выйдет за границы и возьмёт рута. А уязвимость поправят только через 5 лет во время какой-то там верификации. Причем найдут только 1 из 10 уязвимостей.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 15:43
	> Но ведь адепты говорили что факт написания ансейфа будет помогать программисту сильнее > концентрироваться на ошибках в коде, а оказывается не помогает. И хакер > все равно выйдет за границы и возьмёт рута. А гугол-то в курсе? https://www.opennet.ru/opennews/art.shtml?num=61933 >  Методы безопасной работы с памятью позволили существенно снизить число уязвимостей в Android ... > Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году --- > А уязвимость поправят только через 5 лет во время какой-то там верификации. Причем найдут только 1 из 10 уязвимостей. Опять методика 'Пальцем в небо' сертифицированного сотрудника 'НИИ Кекспертизы и вбросов' им. Опеннета?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:25
	Опять повысились надои? А новость сабжевую ты прочитать не хочешь? Чтобы найти вульны нужна аш целая инициатива от целого Амазона. Без этого вульны не ищутся.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 17:32
	> Опять повысились надои? А новость сабжевую ты прочитать не хочешь? Чтобы найти > вульны нужна аш целая инициатива от целого Амазона. Без этого вульны > не ищутся. Опять альтернативная реальность? А то в нашей гугол платит нехилые бабки за каждый найденый вулн: https://opennet.ru/opennews/art.shtml?num=60780 > Из потраченной в 2023 году суммы $3.4 млн (в прошлом году $4.8 млн) выплачено за уязвимости в Android. За информацию об уязвимостях в браузере Chrome было выплачено 359 премий на общую сумму $2.1 млн (в прошлом году $3.5 млн). Че там кстати с твоими чиселками? Я угадал с методикой очередного статистического опеннетного исследования?
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 17:40
	Что та скоростью разработки в 10 раз медленнее? Серво уже дописали? Или может редокс?
	Ответить | Правка | Наверх | Cообщить модератору

14. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
Сообщение от 21yosenior (?), 24-Ноя-24, 12:46
https://github.com/Speykious/cve-rs - там уб в сейфе, толку валидировать ансейф.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
	Сообщение от Карлос Сношайтилис (ok), 24-Ноя-24, 12:58
	Ага, со своей версий transmute. Из стандартной библиотеки "не подошла". https://github.com/Speykious/cve-rs/blob/main/src/transmute.rs
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 13:08
	Хоть со своей, хоть с чьей-то ещё. Заявляется безопасность кода на языке, а не либы - подучи логику. Ансейфа нет, проблемы есть.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 13:35
	>> 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, просто сложив два числа или забыв пустую строку в конце исходника ...
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 13:44
	Всё, ответов не будет? С одного вопроса потеряться - мощно. > cve-rs also contains safe reimplementations of > safe reimplementations Молодец, умножил на ноль тезисы предыдущего героя. Хоть не зря кучу левого мусора спастил.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 14:15
	> Всё, ответов не будет? С одного вопроса потеряться - мощно. Не суметь прочесть три предложения и сразу перейти к "папа, где море?" - намного уныл^W мощнее. >> cve-rs also contains safe reimplementations of >> safe reimplementations > Молодец, умножил на ноль тезисы предыдущего героя. Хоть не зря кучу левого мусора спастил. Молодец, обозвал сигнатуру transmute "левым мусором" и не сумел написать ничего по существу ... зато выдал хороший, объемный выхлоп метана - Газпром гордится тобой!
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:31
	Следует отличать хак, найденный в компиляторе, от намеренного UB в стандарте (sic!) языка программирования. Вы там чуть ниже про логику говорили...
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	61. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 15:37
	У раста нет стандарта. Ты с логикой поссорился ещё очень много лет назад.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:39
	Я про стандарты в таких языках, как Си, Си++
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:38
	ниже ->  ранее
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	73. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:52
	21yosenior У Rust нет спецификации, но есть RFC. Принципиальной разницы на вижу, как и, например, группа разработчиков Gcc,которые работают над своей версией компилятора. Говоря о стандартах, я имел ввиду не Rust, а C, C++. Про какое "воровство" вы тут говорите?
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 16:26
	> Про какое "воровство" вы тут говорите? Я написал про какое. Приведены противоречия лозунгов("гарантирует" и прочее) с реальностью(никаких гарантий). Что ты мне отвечаешь? - "а вот в сишке уб". Никто не спрашивал тебя про сишку, тебя спрашивали про враньё. Но ты начал прятаться за сишку, пытаясь съехать с темы. RFC мусор, который ничего не описывает. Можешь показать мне описание модели памяти в расте. Это принципиальная разница.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от 21yosenior (?), 24-Ноя-24, 15:44
	Покажешь мне стандарт раста. Иди погугли, вернёшься как найдёшь. К тому же, в очередной раз заходы уровня "а у вас негров линчуют". Кто-то говорил здесь про сишку и прочие языки? - нет. Но данный пропагандист почему-то начал прятаться за ними. Это кстати, фундаментальное свойство. Раст состоит из воровства не только по части семантики/компилятора/рантайма/прочего, но также из воровства обоснований своей состоятельности. То есть без пряток за сишку даже сказать никто не смог, что из себя представляет раст и зачем он нужен.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	101. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 17:12
	> Это кстати, фундаментальное свойство. Раст состоит из воровства не только по части семантики/компилятора/рантайма/прочего, ого, ну у тебя бомбануло! а какой компилятор украли? его сначала на окалме писали, потом на самом расте.. даже бекенд на самом расте уже есть > но также из воровства обоснований своей состоятельности. Ты часом не бухаешь? а то логика как-то хромает. > То есть без пряток за сишку даже сказать никто не смог, что из себя представляет раст и зачем он нужен. Для того чтобы сравнить что-то, нужно минимум два операнда. Раст избавляет от типичных ошибок памяти... в чем? в си/с++, а аде и фортране такого же нет.
	Ответить | Правка | Наверх | Cообщить модератору

20. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
Сообщение от Аноним (20), 24-Ноя-24, 13:14
> Компания Amazon и организация Rust Foundation представили инициативу Только один вопрос. Кто им разрешил?
Ответить | Правка | Наверх | Cообщить модератору

	24. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от nume (ok), 24-Ноя-24, 13:41
	А кто запрещал?
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от ijuij (?), 24-Ноя-24, 13:54
	Хороший вопрос! Иногда кажется, что разрешение не требуется.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	39. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (20), 24-Ноя-24, 14:40
	Вопрос не праздный. Вспомним Ada, созданный МО. Да, он есть, но связываться с ним как-то не хотелось и не хочется. За Rust также топит МО. И это тоже как бы намекает. Последствия будут, если не сейчас, так потом. Смотреть надо не сиюминутные выгоды, а на перспективу. Наверное, лучше остаться на относительно свободном C/C++, в том числе для новых проектов.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Прохожий (??), 24-Ноя-24, 15:47
	>За Rust также топит МО. Но не оно является создателем языка, и не оно создаёт компилятор. >И это тоже как бы намекает. Последствия будут, если не сейчас, так потом. Например, какие? >Наверное, лучше остаться на относительно свободном C/C++, в том числе для новых проектов. Группа разработчиков Gcc работает над компилятором Rust, если вы о вендорлоке.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (20), 24-Ноя-24, 16:32
	> Например, какие? Экспортные ограничения.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (98), 24-Ноя-24, 17:03
	МО не занимается вопросами экспорта.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 18:07
	А ещё она медицинскую помощь нелегальным мигрантам не оказывает. Давай больше бессвязных фактов.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (178), 25-Ноя-24, 06:52
	> МО не занимается вопросами экспорта. Безусловно. Вопросами ограничения занимается.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	149. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (13), 24-Ноя-24, 22:28
	> Группа разработчиков Gcc работает над компилятором Rust это фиктивный костылёк чтобы можно было собрать ядро Linux. Полноценный компилятор есть и будет только один под полным контролем корпораций и учитывая что там не GPL тухлый вариант чтобы с ним связываться.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	151. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 23:06
	Тем более нет никаких методик как определить что gcc компиль раста работает так же как штатный компиль раста. И на какую именно версию компиля gcc ровняется на 1.10 или 1.20.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:41
	Вы уже не первый, и, видимо, не последний человек, говорящий про контроль корпораций над чем-то. Хочу вам открыть страшную тайну, только обещайте никому не говорить. Так вот. Все сколь-либо крупные проекты контролируются корпорациями в той или иной степени. И никакая GPL вам не поможет, если корпорации решат перекрыть доступ к открытому ранее коду, даже если у вас будет возможность форкнуть этот самый код. Почему? Потому что создание сколь-либо сложного, годного в употребление ПО требует немалых усилий. Как показывает многолетняя практика, так называемое сообщество не в состоянии без контроля со стороны корпораций тянуть подобные проекты. И они быстро протухают.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	174. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (13), 25-Ноя-24, 03:29
	> И никакая GPL вам не поможет, если корпорации решат перекрыть доступ к открытому ранее коду, даже если у вас будет возможность форкнуть этот самый код. GPL не позволяет закрыть общий код, разве это непонятно ? Пример Linux - вспотеешь его закрывать на законных основаниях потому что для этого потребуется сменить лицензию а для этого потребуется согласие всех участвоваших в разработке - права на код остаются у авторов. > Как показывает многолетняя практика, так называемое сообщество не в состоянии без контроля со стороны корпораций тянуть подобные проекты. мне вообще фиолетово что они там контролируют у Linux - они пишут код для меня и закрыть его не могут. С компиляторами на шланге совсем подругому - оптимизированные компиляторы платные и закрытые (arm compiler, xtensa compiler) а тебе ну может морковки подкинут немного.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 03:38
	> GPL не позволяет закрыть общий код, разве это непонятно ? Пример Linux - вспотеешь его закрывать на законных основаниях потому что для этого потребуется сменить лицензию а для этого потребуется согласие всех участвоваших в разработке - права на код остаются у авторов. Похоже, вы не до конца поняли мою мысль. Вот был проект X, которым владела корпорация Y. На определённом этапе код закрывается. Не тот, который под GPL был написан, а новый код, который добавляет дополнительные фичи. И? Что вы будете делать? Полагаться на сообщество? Я уже написал, оно не потянет. Единственным выходом будет, что такой проект форкнут и потянут уже другие корпорации. Но вы же ярый противник корпораций. Или уже нет? > они пишут код для меня и закрыть его не могут Очень даже могут. Новый код. Не старый, конечно же. Вон, драйвера НВидии, например. Они открыты, несмотря на то, что есть для Линукса?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (13), 25-Ноя-24, 11:09
	> Похоже, вы не до конца поняли мою мысль. Вот был проект X, которым владела корпорация Y. это не мысль а подмена понятий, проектом владеет коммерческая компания и даже если у него есть вариант с открытой лицензией это не открытый проект как Linux а хрень с двойной лицензией, краник перекрыть могут в любой момент > Очень даже могут. Новый код. для этого надо отделить от него старый - давай попробуй, есть примеры для Linux ? > драйвера НВидии, например. это не часть ядра, драйверы GPU работают в юзерспейс, в ядре только малая часть управляющая памятью и имеющая доступ к аппаратным интерфейсам
	Ответить | Правка | Наверх | Cообщить модератору

38. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
Сообщение от Аноним (38), 24-Ноя-24, 14:37
Как насчет верификации хлама, который cargo тащит из-за бугра?
Ответить | Правка | Наверх | Cообщить модератору

	41. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (126), 24-Ноя-24, 14:48
	В суверенных проектах его использовать нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Страдивариус (?), 24-Ноя-24, 15:06
	Пишите свой хлам, размещайте на госуслугах. Cargo поддерживает такое.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	87. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:29
	Это ты сейчас смеёшься, а когда всех пересдачи принудителтно на OneScript я на тебя посмотрю.
	Ответить | Правка | Наверх | Cообщить модератору

59. "Инициатива по верификации стандартной библиотеки Rust"	–4 +/–
Сообщение от Аноним (59), 24-Ноя-24, 15:37
Не могу я понять растохейтеров. Впервые появился инструмент, позволяющий безопасно работать с памятью без ГЦ, без потери производительности, а они только критикуют. Самое смешное, что они критикуют Раст за то, что он не спасает от всех ошибок. "Что ж за безопасность, от всего не защищает, поэтому лучше останусь на Си". Логика классная, да, чем получить хоть какую-то защиту, буду шпарить дальше на абсолютно незащищённым Си.
Ответить | Правка | Наверх | Cообщить модератору

	67. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (8), 24-Ноя-24, 15:41
	Без какой потери производительности? Тесты посмотри. Магии не бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 15:51
	> Без какой потери производительности? Тесты посмотри. Магии не бывает. Ну, посмотрел https://benchmarksgame-team.pages.debian.net/benchmarksgame/... что дальше? "Неправильные тесты, нещитаица!"?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 16:23
	О да тесты на домене 4го уровня. А самому головой подумать? Или как ты делаешь дополнительную работу не задействуя дополнительных команд процессора?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 16:56
	Э.. на этапе компиляции? Если у тебя типы провепяются во время компиляции, если элемент Enum у тебя можно отличить от другого перечисления (и это не задекорированный int как в других языках), если у тебя есть проверки инвариантов, если проверки на null... Да скорость сборки у тебя замедлится, но выполнение может быть на том же уровне.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Инициатива по верификации стандартной библиотеки Rust"	–2 +/–
	Сообщение от Аноним (98), 24-Ноя-24, 17:06
	> тесты на домене 4го уровня Других аргументов, полагаю, нет и не будет.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	112. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 17:50
	Читай до полного усвоения https://habr.com/ru/articles/598219/
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 18:06
	> Читай до полного усвоения https://habr.com/ru/articles/598219/ Ты бы сам прочитал, а то вышел неловкий пук в лужу с твоим rustmustdie: https://www.opennet.ru/openforum/vsluhforumID3/126424.html#247 https://www.opennet.ru/openforum/vsluhforumID3/126424.html#270 Ну, брать дебаг-релиз и сравнивать с gcc-шным выхлопом -O0, как бы уже намекает на уровень (ламерства) ...
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 18:20
	> Читай до полного усвоения https://habr.com/ru/articles/598219/ Кстати, вдогонку насчет рантайма и дабы немного подогреть бедных военов (а то зима,  лужи ведь холодные): https://www.opennet.ru/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 Приходи, когда найдешь тут рантайм.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	133. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Анон1110м (?), 24-Ноя-24, 20:35
	Они специально так сделали. Показуха. Нужно смотреть более серьёзные программы чем вывод строчки текста на экран.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (136), 24-Ноя-24, 20:48
	А ты что из своего раста дергаешь наши Сишные сисколы? Напиши свои на расте, а потом сравнивай уже.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	166. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:50
	Типа Rust - это сферический конь в вакууме? Или что вы хотели сказать? Если сравниваете программу на C, которая дёргает системные вызовы, то почему то же самое запрещено делать на Rust? Надо ведь сравнивать сопоставимые вещи, не правда ли?
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 25-Ноя-24, 08:59
	Тебе намекают что в Раст нет необходимости. Есть языки которые делают тоже самое и даже лучше и на них уже все написано.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 21:18
	В догонку он пишет... Смысл статьи на хабре исключительно про то что чтобы раст был более мене похож на си по скорости нужно очень сильно раст оптимизировать. Ясное дело в проде такое не используют у всех толстые раниаймы оптимизация только для липовых тестов для фанатиков.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	144. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 21:38
	> В догонку он пишет... Смысл статьи на хабре исключительно про то что > чтобы раст был более мене похож на си по скорости нужно Сама статья короткая, но постулирует довольно большой список спорных утверждений, а именно:     Стандартная библиотека неотделима от языка     У него отсутствует нулевой рантайм     В Rust встроен сборщик мусора     Компилятор генерирует медленный машинный код На самом деле набросов еще больше, но достаточно и этого списка. К сожалению, для опровержения этих пунктов мне придется писать максимально уродские хэлло ворлды, которые только можно представить. Хм, т.е. статью ты не читал. Что видно уже по фантазиям "похож на си по скорости". Так-то, там (хабр) автор зачем-то заморочился с собственной реализацияей crt* и сисколов (которые в сишном примере - ничуть не меньше по объему, просто вынесены в отдельные файлы). А вон то выше - вполне на раз опровергает все пункты.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 23:01
	То что автор героически решил проблемы которые есть и доказывает наличие проблем. Но ты конечно же и бревно у себя сзади на заметишь.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 23:38
	> То что автор героически решил проблемы которые есть и доказывает наличие проблем. Конкретный список проблем в студию. А то у тебя то "скорость", то "рантайм" - но, как обычно, ничего конкретного. > Но ты конечно же и бревно у себя сзади на заметишь. Ух, очередная аргументативная аргументация Военов.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 25-Ноя-24, 09:01
	Ну подумай какая проблема есть у тормозного и небезопасного языка Раст.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 17:13
	> О да тесты на домене 4го уровня. О, опоздавший родиться и не слышавший о "The Computer Language Benchmarks Game", зато топящий за сишку? Ну, бывает, особенно у неофитов. > А самому головой подумать? Или как ты делаешь дополнительную работу не задействуя дополнительных команд процессора? Короче, тестов сравнимых по качеству хотя бы с бенчмарк-геймом не будет, будет лишь вода и "нещитаица".
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	109. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
	Сообщение от Аноним (126), 24-Ноя-24, 17:44
	>зато топящий за сишку? Ну, бывает, особенно у неофитов. Неофит - новый сторонник какой-либо религии. Новыми можно назвать адептов Rust. Так что, как то, неправильное употребление слова.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 17:54
	Он ещё даже вуз не окончил, а уже пытается умные слова употреблять.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:59
	Хорошо, что вы ВУЗ закончили. Плохо то, что это времяпрепровождение прошло для вас бесцельно.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 25-Ноя-24, 09:02
	По себе судишь не надо так.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Инициатива по верификации стандартной библиотеки Rust"	–2 +/–
	Сообщение от Прохожий (??), 25-Ноя-24, 02:57
	Придирки к одному единственному слову, игнорируя общий смысл сказанного... Таки он прав в том, что религиозны не программисты на Rust, а программисты на C. И вы - яркий тому пример.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	111. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 24-Ноя-24, 17:50
	Подгонять что угодно под тесты любимая задача для очковтирателей.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	115. "Инициатива по верификации стандартной библиотеки Rust"	+2 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 17:57
	> Неофит - новый сторонник какой-либо религии. > Новыми можно назвать адептов Rust. А Воены Супротив Раста - это члены древнего и уважаемого Ордена Защиты Вселенной от Ржавой Угрозы, ага. > Без какой потери производительности? Тесты посмотри. Магии не бывает. > Подгонять что угодно под тесты любимая задача для очковтирателей. А ты самокритичен! Правда, тесты так и не предоставил. Ну и не очень понятно, какие именно религиозные обеты не дают написать Военам более правильные тесты на правильных ЯП в Shootout-e?
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (193), 25-Ноя-24, 09:45
	В любой прикладной задаче, где потребуется передать владение каким-либо массивом объектов или их свойств, раст сразу садится а лужу.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	170. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (170), 25-Ноя-24, 03:02
	> Впервые появился инструмент, позволяющий безопасно работать с памятью без ГЦ, без потери производительности, а они только критикуют. Потому что раст не позволяет безопасно работать с памятью и теряет производительность. Но что более важно раст добавляет кучу других минусов: он очень архаичен в синтаксисе и дизайне, его напрямую контролируют 3 корпорации зла (что может пойти не так?), его архитектура и дизайн его экосистемы бездарна (объединим линтер и компилятор, что может пойти не так? почему бы не добавить в язык еще язык макросов, вместо того чтобы избавиться от них...), у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает). Ты предлагаешь отказаться от одного архаичного и уже состоявшегося языка с поддержкой примерно везде ради другого архаичного языка, не менее дырявого, но при этом с явными новыми проблемами. Так еще и у языка вполне себе конкретные владельцы которые в любой момент прикроют лавочку. А главный аргумент почему нужно перейти это весьма узкие проблемы при работе с памятью и то только для программ где не важна производительность. Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеля или на управляемые вроде питона или джавы или уже смириться и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблере. Если уж и менять стек, то на что-то адекватное, а не на это маркетинговое !@#$%. > Самое смешное, что они критикуют Раст за то, что он не спасает от всех ошибок. "Что ж за безопасность, от всего не защищает, поэтому лучше останусь на Си". Логика классная, да, чем получить хоть какую-то защиту, буду шпарить дальше на абсолютно незащищённым Си. Незащищенным от чего? Где используют? В 99% либо используют либы на современных плюсах, где большинство проблем решены, и нет смысла менять стек на раст чтобы получить в моменте больше проблем, а в перспективе получить еще больше проблем.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	173. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (59), 25-Ноя-24, 03:21
	> он очень архаичен в синтаксисе и дизайне И что же архаичного в синтаксисе и дизайне Раста? Он напротив современен - в нем, к примеру, подчеркивается стремление к иммутабельности переменных, чисто функциональная идея, которая пошла в мейнстрим лишь недавно. > раст не позволяет безопасно работать с памятью Позволяет. Недаром борроу-чекер есть > теряет производительность. Незначительно. В Расте нет ГЦ, во время компиляции всё просчитывается благодаря борроу чекеру, поэтому накладных расходов если и больше чем в Си, но сильно меньше, чем в Джавах и прочих Гоу. Уверен, компилятор Раста в дальнейшем может и перегнать сишку. > Ну тогда или нужно смотреть на самом деле безопасные и верифицируемые языки вроде хаскеля или на управляемые вроде питона или джавы или уже смириться и стараться писать безопасные программы на быстрых языках вроде того же си/на ассемблере. Хаскелл да, респект, функциональное программирование я уважаю. Но вот с питоном и джавой - суть как раз в том, что мы получаем те же гарантии по памяти, что в питоне и джаве, но без медленного ГЦ > у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает). Так борроу чекер да, и есть киллер-фича. Он снимает столько проблем, что уже обеспечивает полезность Раста. В целом не могу понять, откуда у вас эта мантра про "нет производительности, лучше уж джава". Да Джава ж медленее гораздо.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Прохожий (??), 25-Ноя-24, 03:33
	> Потому что раст не позволяет безопасно работать с памятью и теряет производительность. Проверка работы с памятью проводится на этапе компиляции, а не на этапе выполнения. Поэтому нет, программы на Раст в производительности обычно не теряют (кроме отдельных специфичных случаев, таких, например, как цикл по массиву, в котором происходят проверки на выход за границы диапазона, но эти проверки при определённых навыках можно обходить). > он очень архаичен в синтаксисе и дизайне Надеюсь, вы понимаете смысл слова "архаичен"? Rust и 20 лет нет. Поэтому его синтаксис никак нельзя назвать архаичным, в отличие, например, от синтаксиса того же C. > его напрямую контролируют 3 корпорации зла (что может пойти не так?) Не контролируют, а спонсируют разработку. Да, могут отказаться от финансирования. Но это с любым проектом такое может произойти в нашем мире. > его архитектура и дизайн его экосистемы бездарна (объединим линтер и компилятор, что может пойти не так? И что же? > почему бы не добавить в язык еще язык макросов, вместо того чтобы избавиться от них...) Зачем в C макросы используют? Или в Плюсах? И почему в Rust макросы - лишние, по-вашему? > у него нет реально стоящих фич ради которых на него нужно переходить (по сути только борроу чекер, который при этом жестко ограничивает) По сути, вы вообще ничего не знаете об этом языке, а так смело и безаппеляционно о нём высказываетесь почему-то. Что, впрочем, неудивительно для "экспертов" местного пошиба. Алгебраические типы данных, безопасная работа с памятью, строгая типизация, контроль выхода за пределы массива, встроенные макросы, поддержка разных парадигм программирования, исчерпывающий паттерн-матчинг, отличные стандартные типы из коробки, поддержка Юникод из коробки, 0-cost абстракции... И так далее, и тому подобное. > Если уж и менять стек, то на что-то адекватное Например? > а не на это маркетинговое !@#$%. Гугл, Амазон, Клаудфлэр, Дискорд, Дропбокс и некоторые другие так не считают почему-то. Не задумывались почему? > Незащищенным от чего? Вы читать хоть немного не пробовали, прежде чем писать подобные утверждения или задавать подобные вопросы? От ошибок работы с памятью. От UB. От нестрогой типизации.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	179. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (178), 25-Ноя-24, 06:54
	> Впервые нет > появился инструмент, позволяющий безопасно работать с памятью без ГЦ нет > без потери производительности нет
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

107. "Инициатива по верификации стандартной библиотеки Rust"	–2 +/–
Сообщение от Аноним (-), 24-Ноя-24, 17:40
>За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости. Кто тут говорил, что Раст безопасен?
Ответить | Правка | Наверх | Cообщить модератору

	113. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 17:53
	Раст небезопасен там есть unsafe
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Прохожий (??), 25-Ноя-24, 03:06
	В данном случае следовало бы сказать, что не Rust, а некоторые библиотечные функции.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 25-Ноя-24, 08:55
	На безопасном языке невозможно написать небезопасную библиотеку. Головой поработай чутка.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Прохожий (??), 25-Ноя-24, 03:05
	Я говорил. Но всегда уточнял, что безопасность касается только типовых ошибок работы с памятью, а не вобще всех на свете, от которых может спасти только формальная верификация, как здесь уже отмечали. Однако эта верификация - процесс медленный, очень дорогой, и поэтому далеко не всегда целесообразный.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	184. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 25-Ноя-24, 08:57
	Go тоже безопасность от типовых ошибок.
	Ответить | Правка | Наверх | Cообщить модератору

130. "Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от Bottle (?), 24-Ноя-24, 20:00
А толку, если у язычка нет спецификации? Он небезопасен by design, парадоксально, но даже Си безопаснее, потому что минимальная работа по стандартизации проведена.
Ответить | Правка | Наверх | Cообщить модератору

	134. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (-), 24-Ноя-24, 20:39
	Это вы про тот стандарт, которым подтираются (-fno-strict-aliasing) чтобы собрать ядро linux?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Инициатива по верификации стандартной библиотеки Rust"	–1 +/–
	Сообщение от Аноним (45), 24-Ноя-24, 21:18
	> А толку, если у язычка нет спецификации? Он небезопасен 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;   }   /* ... */ } красота, че!
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	141. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
	Сообщение от Аноним (50), 24-Ноя-24, 21:31
	Как это оптимизировать чтобы код выполнялся за минимальное количество тактов? Да никак код или быстрый или безопасный или рыжая морда опять звездит.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 21:44
	> код или быстрый или безопасный или ... поведение просто определеной и у тебя не будет UB. А просто будет two's complement wrapping. Получается и быстро, и безопасно, и главное предсказуемо. Поведение едино для языка, а не приколочено к платформе, компилятору, флагам, фазе луны...
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (45), 24-Ноя-24, 22:17
	> Как это оптимизировать чтобы код выполнялся за минимальное количество тактов? > Да никак код или быстрый или безопасный или рыжая морда опять звездит. Ну, с высоты опеннетных, совсем не палящихся кекспердов-теоретиков все может быть. А так-то: if (__builtin_sadd_overflow(si_a, si_b, &sum)) и будет из всех проверок на (не очень экзотических) платформах условный JO/BVS, вместо вон того вон. Работает в шланге, gcc и icc - ну это кому шашечки.
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	143. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 24-Ноя-24, 21:34
	> но даже Си безопаснее Си дыряв прям по его убогому недостандарту. Потому что назвать, да и еще и хвастаться, стандартом то, в чем 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 И это не учитывая разное поведение разных компиляторов и даже версий одного компилятора. Ну и где дыряшка безопаснее?
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

153. "Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от Аноним (153), 24-Ноя-24, 23:19
Сапожник то без сапог!
Ответить | Правка | Наверх | Cообщить модератору

181. "Инициатива по верификации стандартной библиотеки Rust"	+1 +/–
Сообщение от Аноним55 (?), 25-Ноя-24, 08:08
Предполагаю, что истинной целью проекта Rust является отвлечение ресурсов потенциальных конкурентов на изучение бесперспективного проекта и бессмысленные дискуссии. Это известные действия, и в науке даже имеют специальный термин - "троянское обучение".
Ответить | Правка | Наверх | Cообщить модератору

	182. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (50), 25-Ноя-24, 08:52
	Да методичку по саботажу никто пока что не менял и не исправлял.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (-), 25-Ноя-24, 09:28
	> Да методичку по саботажу никто пока что не менял и не исправлял. А откуда у вас информация, что методичку не поменяли? Палитесь, товарищ!
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Аноним (193), 25-Ноя-24, 09:41
	Вы не понимаете, это всё - борьба с безработицей. Так же как и крипта.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

191. "Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от Аноним (191), 25-Ноя-24, 09:37
>в 7500 встречаются блоки кода, выполняемые в контексте "unsafe". За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости. Такая вот безопасТная безопасность ;)
Ответить | Правка | Наверх | Cообщить модератору

194. "Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от Сергей (??), 25-Ноя-24, 09:49
Я правильно понимаю, обнаружив уязвимость в единственой библиотечке RUST, я поимею доступ ко всему, что создано на RUST
Ответить | Правка | Наверх | Cообщить модератору

	195. "Инициатива по верификации стандартной библиотеки Rust"	+/–
	Сообщение от Нонон (?), 25-Ноя-24, 10:36
	Это должна быть как минимум популярная библиотека. А чем популярнее библиотека тем более умные люди там пишут. И вряд ли будут косячить в блоках unsafe. Нали блоки unsafe им в принципе надо Самые большие косяки в unsafe делают мамкины программисты. У которых это возможно это их первый язык. И они почему-то решили побаловаться с unsafe. Но их крэйты никому не нужны
	Ответить | Правка | Наверх | Cообщить модератору

198. "Инициатива по верификации стандартной библиотеки Rust"	+/–
Сообщение от Аноним (198), 25-Ноя-24, 11:04
без сертификата встек никуда не годится
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема