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

"Выпуск Rust 1.86. Подготовка официальной спецификации языка Rust"	+/–
Сообщение от opennews (?), 03-Апр-25, 23:36
Опубликован релиз языка программирования общего назначения Rust 1.86, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63015
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+12 +/–
Сообщение от Унитаз (?), 03-Апр-25, 23:36
Хороший релиз
Ответить | Правка | Наверх | Cообщить модератору

	135. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–5 +/–
	Сообщение от Аноним (135), 04-Апр-25, 09:16
	Вроде всё хорошо, кроме одного - где IDE? Хорошая бесплатная опенсорсная IDE. Растоманы даже нормальную IDE себе создать не могут. Джависты им сделали проприетарный Rust Rover, и теперь растоманы говорят, что это лучшее, что у них есть.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+6 +/–
	Сообщение от morphe (?), 04-Апр-25, 11:18
	Есть LSP сервер rust-analyzer, который работает с vim, emacs, vscode, и десятком других редакторов кода, что ещё нужно?
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 04-Апр-25, 11:34
	> и десятком других редакторов кода, что ещё нужно? Зачем мне десяток редакторов уровня notepad, если мне нужна одна мощная IDE по типу Rust Rover, только бесплатная, опенсорсная и желательно написанная на расте.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (174), 04-Апр-25, 11:39
	RustRover Free for non-commercial use - мало?
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от freecoder (ok), 04-Апр-25, 13:28
	Чем IDE принципиально отличается от редактора кода с плагинами? Чем не устраивает VSCode/VSCodium/Zed с rust-analyzer?
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	229. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (135), 04-Апр-25, 13:32
	Всё должнл быть сразу из коробки интегрированно.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от freecoder (ok), 04-Апр-25, 14:09
	> Всё должнл быть сразу из коробки интегрированно. Даже то, что тебе в работе не нужно? Извините, но это уже устаревший подход.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (275), 04-Апр-25, 15:00
	>> Всё должнл быть сразу из коробки интегрированно. > Извините, но это уже устаревший подход. Интеграция в *интегрированной* среде разработки? Действительно, бред какой-то...
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 19:11
	> Интеграция в *интегрированной* среде разработки? > Действительно, бред какой-то... Ну так ты ставишь плагин и он интегрируется! И тебе не нужно запускать тот же дебагер отдельно - он *интегрируется* в твою IDE
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от morphe (?), 04-Апр-25, 20:05
	> Всё должнл быть сразу из коробки интегрированно. А можно немного конкретнее, что там недостаточно интегрировано? Потому что я долго работал в разных IDE, и мне честно непонятно что от них нужно для Rust В IDE полезна интеграция фреймворков, у которых разные паттерны компиляторами не проверяемые (названия методов в жаве например/аннотации там же)/кодогенерация, понимание которой нужно для автокомплита и прочего (lombok в той же жаве), и т.д, но в Rust то всё нужное для этого уже из коробки интегрировано, даже такие сложные штуки как bevyengine не требуют ничего того что могла бы предоставить IDE
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	260. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 14:33
	IDE предполагает наглядно видеть создаваемый интерфейс приложения. Опять сервер rust-analyzer будет видеть чужой код
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

	279. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (275), 04-Апр-25, 15:02
	> Чем IDE принципиально отличается от редактора кода с плагинами? У тебя ответ буквально под новом в первой бкуве аббривеатуры IDE. В интегрированности.
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

	284. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (284), 04-Апр-25, 15:09
	Так почему не пишешь?
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	320. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 04-Апр-25, 16:50
	Что?
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (284), 04-Апр-25, 17:23
	Почему не пишешь мощную IDE по типу Rust Rover, только бесплатную, опенсорсную и желательно на расте?
	Ответить | Правка | Наверх | Cообщить модератору

	436. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 05-Апр-25, 09:15
	Ну почему не пишу, пишу, но только не для раста, и не на расте.
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (347), 04-Апр-25, 18:04
	С каких это пор мегажрущая помойка на Java стала "IDE"?
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

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

	386. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от morphe (?), 04-Апр-25, 20:07
	> Зачем мне десяток редакторов уровня notepad, если мне нужна одна мощная IDE > по типу Rust Rover, только бесплатная, опенсорсная и желательно написанная на > расте. По моему опыту с rust-analyzer работать приятнее чем с Rust Rover, и там всё уже есть, есть какая-то конкретика, что RustRover предоставляет, а rust-analyzer в любом из поддерживаемых редакторов - нет?
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	413. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от fuggy (ok), 04-Апр-25, 23:50
	Как это можно сравнивать rust-analyzer это же LSP. Всё что LSP предоставляет можно подключить к любому редактору, если он это поддерживает. А Rust Rover это IDE и использует под капотом свои подсказки и валидаторы. И к нему можно тоже подключить внешний rust-analyzer через плагин.
	Ответить | Правка | Наверх | Cообщить модератору

	470. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от morphe (?), 06-Апр-25, 02:51
	> Всё что LSP предоставляет можно подключить к любому редактору, если он это поддерживает Т.е нужен вендорлок, или что? Что конкретно умеет rust rover, чего не умеет условный vscode с rust-analyzer? > И к нему можно тоже подключить внешний rust-analyzer через плагин. Плагин для поддержки LSP в идее сделан плохо, и не умеет половины фич, rust-analyzer в idea никто не использует просто потому что он там криво работает в отличии от редакторов которые изначально ориентируются на LSP, а не делают своих решений как идея.
	Ответить | Правка | Наверх | Cообщить модератору

	396. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (396), 04-Апр-25, 21:05
	А у каких языков есть есть мощная, бесплатная, оперсорсная IDE написанная на том же языке? Неироничный выопрос, мне правда интересно. Только без Eclipse, Netbeans, code::blocks
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	401. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от maximnik0 (?), 04-Апр-25, 21:31
	Чувствую холливар но удержаться не могу -Lazarus.
	Ответить | Правка | Наверх | Cообщить модератору

	471. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (471), 06-Апр-25, 02:54
	Сам напиши, в чем проблема-то?
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	173. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 11:34
	bruh... https://github.com/zed-industries/zed
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	176. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 04-Апр-25, 11:40
	> Zed is a code editor from the creators of Atom Это точно что-то хорошее?
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 11:48
	В чем проблемы? В этом году обещают релиз 1.0, можешь заценить после выпуска. Пока что дебаггера нет в основной ветке и баги небольшие встречаются, но всяких крашей из-за случайных unwrap-ов не встречал.
	Ответить | Правка | Наверх | Cообщить модератору

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

	453. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 05-Апр-25, 19:28
	Попробовал. Так и знал, что это неполноценная IDE.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	188. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 04-Апр-25, 12:01
	Список "хороших бесплатных опенсорсных IDE" для других ЯП, представь на суд общественности.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	213. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–5 +/–
	Сообщение от Аноним (135), 04-Апр-25, 12:52
	IntelliJ IDEA - лучшая IDE в мире.
	Ответить | Правка | Наверх | Cообщить модератору

	398. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (396), 04-Апр-25, 21:06
	Но при этом чисто коммерческая и не опенсорс. idea community - огрызок.
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 04-Апр-25, 22:24
	Коммерческая там ultimate, а в community есть всё что нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Rev (ok), 04-Апр-25, 12:28
	Так напиши! В чём проблема? Тебе и язык надо бесплатно разработать, а потом бесплатно тебе ещё и IDE написать? А не много ли ты хочешь, халявщик?
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	215. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–4 +/–
	Сообщение от Аноним (135), 04-Апр-25, 12:54
	Ну и зачем мне тогда сдался раст? Если есть другие бесплатные языки с хорошими IDE.
	Ответить | Правка | Наверх | Cообщить модератору

	424. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Прохожий (??), 05-Апр-25, 02:57
	То есть, сам язык программирования вам не нужен (не интересен), если там нет IDE? VSCode с Rust-analyzer не подходит только тем, что надо лишний раз на клавиатуре поклацать, чтобы этот плагин поставить из маркета? А вы точно программист?
	Ответить | Правка | Наверх | Cообщить модератору

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

	442. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от incorporate (?), 05-Апр-25, 13:35
	А в чем проблема купить проприетарную IDE? Ни разу не слышал чтобы те же  уважаемые натуралы требовали себе бесплатный комп для разработки софта. Вообще это что-то новое в мире опенсорса, когда халявщики начинают ТРЕБОВАТЬ халявы.
	Ответить | Правка | Наверх | Cообщить модератору

	446. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (135), 05-Апр-25, 15:27
	> А в чем проблема купить проприетарную IDE? Зачем, если есть прекрасная бесплатная IntelliJ IDEA? Единственно она жирновата, но это простительно. > бесплатный комп Это другое. > ТРЕБОВАТЬ халявы А что касается раста, то о расте должны позаботится разработчики раста, и создать для него IDE. А если не хотят, то и не надо, кто их заставляет. Сам я растоманом не являюсь, поэтому зачем мне для него IDE делать или покупать? Я себе другую IDE делаю.
	Ответить | Правка | Наверх | Cообщить модератору

	464. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 23:17
	> А что касается раста, то о расте должны позаботится разработчики раста, и > создать для него IDE. А если не хотят, то и не > надо, кто их заставляет. Дык уже есть плагин rust-analyzer для любой IDE, которая поддерживает LSP. Зачем изобретать велосипед?
	Ответить | Правка | Наверх | Cообщить модератору

	472. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (471), 06-Апр-25, 02:58
	> Вообще это что-то новое в мире опенсорса, когда халявщики начинают ТРЕБОВАТЬ халявы. Разве новость? Всегда было, причем отдельные заходы воистину фееричны - https://www.fsf.org/windows/upcycle-windows-7 примером.
	Ответить | Правка | К родителю #442 | Наверх | Cообщить модератору

	462. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 23:09
	>> А вы точно программист? > Самый натуральный и уважающий себя. Не верю (c). > Поэтому я и ищу себе эффективный инструмент по вкусу, а не кучу гемора с дополнительными настройками. Эта "куча гемора" заключается только в том, чтобы в несколько кликов мышкой установить нужный плагин, который скачается и установится с помощью IDE самостоятельно. И вы получите все плюшки, которые есть в монолитной IDE. Кроме того, вряди ли в монолитную IDE вы сможете интегрировать такую, иной раз, полезную вещь, как AI-помощник или любой другой плагин, который может быть полезен вам для работы. Почему? Потому что IDE же монолитная, то есть не подразумевает наличие каких-либо плагинов. Далее, обычно монолитная IDE поддерживает только какой-то один язык программирования. Это означает, что с переходом на другой ЯП, вам придётся искать другую IDE и переучиваться работать уже с ней. Всё сказанное выше заставляет меня сильно усомниться в истинности вашего высказывания о том, что вы "ищете себе эффективный инструмент". Потому что процесс переучивания (когда этого можно не делать) нельзя назвать эффективным занятием.
	Ответить | Правка | К родителю #435 | Наверх | Cообщить модератору

9. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+13 +/–
Сообщение от Аноним (9), 03-Апр-25, 23:48
Блин, какой же корявый синтаксис, не выразительный, не красивый, жуть какая-то... Куча двоеточий, какие-то мутные 'fn', 'let'... не могли синтаксис покрасивее сделать что-ли, чтобы легче читался? (
Ответить | Правка | Наверх | Cообщить модератору

	14. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Krtek (?), 03-Апр-25, 23:56
	Согласен, на этом писать можно, разве что, за очень большие деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (38), 04-Апр-25, 01:14
	Погуглите по слову "индус". Узнаете много нового. На многое откроются глаза.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от zionist (ok), 04-Апр-25, 02:20
	Ну так это же хорошо. Если мозгов это выучить хватит, будешь больше зарабатывать.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	129. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Андрей (??), 04-Апр-25, 08:28
	Так никто не будет платить больше, просто будут делать ставку на пиар, мутных фанатиков и амортизацию расходов на багах - если амортизация покажет, что на якобы безопасном расте можно писать в два раза медленнее, совершая на 10% меньше ошибок(часть из которых хорошо ловят статические анализаторы), при том без гарантий что без ошибок(логических ошибок сильно больше и они часто сложнее, чем ошибки с памятью, вспоминаем копипасту, дубли веток, синтаксически корректные опечатки и пр.)
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Rev (ok), 04-Апр-25, 12:30
	Я тоже когда-то думал, что на Расте писать медленнее, но при этом не терять потом время на выявление ошибок и фиксы. Но потом я лучше выучил Раст, и могу с уверенностью сказать, что писать на нём можно быстрее, чем на С++. И не тратить время на фикс идиотских багов потом.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Аноним (257), 04-Апр-25, 14:23
	может стоит лучше выучить C++?
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 14:43
	>может стоит лучше выучить C++ Об этом можно было говорить лет 15 назад. Сейчас это невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 17:06
	> может стоит лучше выучить C++? За 21 день, я надеюсь? Иначе даже не предлагайте :)
	Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

	346. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (346), 04-Апр-25, 18:00
	Все что было написано на предыдущем Раст'е было написано на предыдущем Растёт, в случае с С++ ещё можно отпетлять
	Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

	20. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+6 +/–
	Сообщение от Аноним (20), 04-Апр-25, 00:04
	Все эти сокращения и закорючки сделаны чтобы ты сконцентрировался на алгоритме. Ты же вживил себе чип с расшифровкой закорючек?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	23. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (9), 04-Апр-25, 00:08
	С такими закорючками фиг сконцентрируешься, а если вдруг отвлекся ненадолго, то затем придётся по новой "парсить" код, пытаясь понять, чего ж ты там наконцентрировал )
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (20), 04-Апр-25, 00:14
	Лошара, я ж тебе говорю чип вживляй. Конечно есть вариант обратиться к знакомому рептилоиду, но тогда навсегда станешь его агентом, а это уже и спалить могут.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (37), 04-Апр-25, 01:08
	Не нужон этот ваш киберпанк тут.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (96), 04-Апр-25, 05:53
	> киберпанк Интернет они тут увздумали подключать.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Rev (ok), 04-Апр-25, 12:32
	Так поставь себе нормальную IDE, с которой не надо концентрироваться на закорючках. Она сама подсветит всё, что ты где-то пропустил или не так написал.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	177. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (177), 04-Апр-25, 11:41
	Так в том то и дело, что это не сокращения. Синтаксис длиннее, чем в c++. fn func(x: i32) -> i32 длиннее, чем int func(int x)
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	228. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от freecoder (ok), 04-Апр-25, 13:31
	fn func(x: isize) -> isize
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 14:19
	Первая запись более информативная, не допускающая двусмысленность int Если мы будем создавать функции с более сложными возвращаемыми значениями, то начнётся огород из (). В rust же видно сразу, что возвращает функция.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	467. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Bottle (?), 06-Апр-25, 01:00
	Ты даже не эквивалентные записи привёл. i32 ≠ int, скорее i32 = int_32_t. Если и сравниваешь, то давай без подлога. У тебя тип int в C/C++ переменной длины, в зависимости от религиозных убеждений авторов компилятора. То есть если авторы захотят, этот тип будет у тебя занимать 64 бита вместо 32х, да, двойной жор памяти возможен, всё ради мнимой скорости.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	256. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 14:22
	Вы в самом деле вчитываетесь в структурные закорючки? На днях настраивал парсер Notepad++ для нового языка. Реальные слова в качестве "структурных закорючках" крайне неудобны. Парсер путает их с комментариями
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	25. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от НяшМяш (ok), 04-Апр-25, 00:13
	Да, сяшечная куча *****(((((((()))))))))void*void*void*------>>>>>>>>>> намного лучше. Про кресты можно вообще не вспоминать.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	29. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (29), 04-Апр-25, 00:30
	Если ты не вчера родился, но сишечку в своё время ругали за эту мутотень. Только вот хрустик решил расширить и углубить это направление. std::ptr::null::<u8>(), ппц. Да тут кресты нервно курят со своими 100500 шаблонами.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+4 +/–
	Сообщение от Аноним (275), 04-Апр-25, 10:41
	> Если ты не вчера родился, но сишечку в своё время ругали за эту мутотень Да? И что предлагали взамен? Паскаль? > хрустик решил расширить и углубить это направление. std::ptr::null::<u8>(), ппц. Да тут кресты нервно курят Ты кресты в глаза не видел, потому что приведенный тобой код ни чем не отличается от полюсовых неймапейсов типа std::vector<std::uint8_t>.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (29), 04-Апр-25, 11:40
	>Да? И что предлагали взамен? Паскаль? Кроме паскаля ничего не знаешь? >ни чем не отличается от полюсовых неймапейсов типа std::vector<std::uint8_t>. Если уж сравнивать, то с std::uint8_t. Зачем ты поверх ещё контейнер наворотил? Любишь подменять понятия?
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (189), 04-Апр-25, 12:04
	Причем у большинства это будет просто uint8_t.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Аноним (193), 04-Апр-25, 12:10
	> Кроме паскаля ничего не знаешь? Так ты на вопрос-то ответишь? > Если уж сравнивать, то с std::uint8_t. Да? А почему не с std::chrono::time_point<std::chrono::system_clock>? "Вы не понимаете, это другое!" > Зачем ты поверх ещё контейнер наворотил? Ну ты же синтаксисом возмущался. А оказалось, в плюсах (которые ты в жизни не видел) он ничем не лучше. Причем еще с 80х годов, лол.
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	133. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Андрей (??), 04-Апр-25, 08:42
	Синтетические примеры это так клёво, редкость упомянутых случаев это так уныло
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	468. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Bottle (?), 06-Апр-25, 01:03
	Если будет возможность писать дурной код, люди будут ей пользоваться. Поэтому да, это важно. Лиспы дрянь по этой причине, кстати, благодаря макросам каждый придумывает свой диалект, в итоге получаем вавилонскую башню в коде.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Аноним (177), 04-Апр-25, 11:45
	> Да, сяшечная куча *****(((((((()))))))))void*void*void*------>>>>>>>>>> намного лучше. Про кресты можно вообще не вспоминать. Это скорее растовый код
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	35. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 04-Апр-25, 00:40
	Мусье, питоны и паскали обсуждают в других темах, здесь обычный С-подобный синтаксис. Пожалейте свою психику и закройте вкладку бравзера.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	39. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от User (??), 04-Апр-25, 01:24
	>здесь обычный С-подобный синтаксис. Как будто в этом есть что-то хорошее...
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от анонимус (??), 04-Апр-25, 19:29
	Ничего лучше ещё не придумали, ибо приходится выбирать между многословностью и простотой чтения.
	Ответить | Правка | Наверх | Cообщить модератору

	388. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от User (??), 04-Апр-25, 20:09
	> Ничего лучше ещё не придумали, ибо приходится выбирать между многословностью и простотой > чтения. Ну да, ну да - по тому и книжки мы читаем закорючками - иначе очень уж букаф многа, ниасилить никак...
	Ответить | Правка | Наверх | Cообщить модератору

	469. Скрыто модератором	+/–
	Сообщение от Bottle (?), 06-Апр-25, 01:08
	Да-да, амперсанды в качестве ссылок, двойные амперсанды в качестве И-гейта, двойные равенства в качестве равенства, звёздочки в качестве обращения при таких же звёздочках в качестве умножения это ПИК дизайнерской мысли. Выворачивание смыслов наизнанку вместо следования выработанной норме.
	Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

	49. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Нуину (?), 04-Апр-25, 02:06
	Можешь глянуть на mojo -- синтаксис питона, но с боровым и мув конструкторами.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	94. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (96), 04-Апр-25, 05:52
	> mojo Muddy Waters - Got My Mojo.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Вася Пупкин (?), 04-Апр-25, 02:20
	Хоть синтаксис в языке совсем не главное, но в расте он точно логичнее чем в плюсах, начиная с базы с его 100500 видов конструкторов и более компактным объявлением функций. хотя вроде его плюсы пытались своровать с растового с его явным self с модификаторами
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	178. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (177), 04-Апр-25, 11:44
	fn func(x: i32) -> i32 длиннее, чем int func(int x)
	Ответить | Правка | Наверх | Cообщить модератору

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

	144. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Соль земли (?), 04-Апр-25, 10:08
	Просто мегапридирка, очень умная и самое главное оригинальная.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	165. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (275), 04-Апр-25, 11:17
	> Просто мегапридирка, очень умная и самое главное оригинальная. А к чему еще может придраться человек, не имеющий отношения к программированию и разработке ПО? Ну вот серьезно? Это добрые 95% местых комментаторов.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Jh (?), 04-Апр-25, 11:02
	Говорят, сейчас код ИИ пишет, а ему пофиг как выглядит.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	163. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (275), 04-Апр-25, 11:14
	> Говорят, сейчас код ИИ пишет, а ему пофиг как выглядит. Все так, но об этом здесь говорить не принято. Тут недавно один комментатор уверял, что люди, считающие в уме при помощи листика бумаги, дают прикурить целому бухгалтерскому отделу с Экселями по скорости и точности вычислений. А ты про ИИ...
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 11:16
	>Блин, какой же корявый синтаксис Как и ожидалось от ыкспертов, ничего кроме синтаксиса не0силили
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	199. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (199), 04-Апр-25, 12:16
	У нас уже был понятный синтаксис - Паскаль. И где он сейчас? Нормальный программист освоит синтаксис любого современного языка (и раст - не исключение) за пару дней. Ну, ладно, особенно туговатые - за неделю. Гуанокодеры, которые не могут освоить даже синтаксис, всё равно кроме гуанокода ничего написать и не могут. Их лучше к программированию и не подпускать вовсе.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	351. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (351), 04-Апр-25, 18:25
	https://castle-engine.io/why_pascal
	Ответить | Правка | Наверх | Cообщить модератору

	443. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от incorporate (?), 05-Апр-25, 13:38
	>> не могли синтаксис покрасивее сделать что-ли, чтобы легче читался? О! Разрабы 1С подтянулись на опеннет
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	465. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 23:23
	> Блин, какой же корявый синтаксис, не выразительный, не красивый, жуть какая-то... Куча > двоеточий, какие-то мутные 'fn', 'let'... не могли синтаксис покрасивее сделать что-ли, > чтобы легче читался? ( Интересно, вы к математике или к физике такие же претензии выдвигаете? Зачем все эти значки с закорючками, надо же было писать на естественном языке, типа, вместо "+" - "плюс" и т.д. Код на Rust читается легко, если вы понимаете семантику языка. А вы её, очевидно, не понимаете. Если же вам всё ещё нужно понимание кода на Rust, но при этом вы не хотите тратить время на обучение, рекомендую воспользоваться помощью какой-нибудь LLM. Они обычно очень хорошо переводят с Rust на тот язык, на котором вы разговариваете.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

15. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+4 +/–
Сообщение от ИлонМаск (?), 03-Апр-25, 23:59
О, Rust, конечно, молодец — «безопасность, иммутабельность, borrow checker»… Как же без этого! Прямо рай для параноиков, которые боятся собственного кода. А вот в C и C++ мы живём по-настоящему:     Хочешь UB (Undefined Behavior)? Пожалуйста! Это же особенность, а не баг.     Нужно сделать reinterpret_cast указателей? Да хоть в void* и обратно! Rust бы уже десять unsafe вставил.     Многопоточность? В C++ хоть std::thread, хоть сырые pthreads, хоть атомики с memory_order_relaxed — полная свобода стрелять себе в ногу!     Производительность? В C/C++ компиляторы десятилетиями оптимизируют код так, что Rust только снится. И самое главное — нам не нужен borrow checker, чтобы чувствовать себя живыми. Мы сами решаем, когда освобождать память. Это как ездить без подушек безопасности — зато адреналин! Так что да, Rust — это, конечно, мило. Но если хочется настоящего контроля (и хаоса), добро пожаловать в C/C++, где ты — настоящий хозяин своей судьбы (и segmentation fault'ов). 🚀💥 P.S. А ещё в C++20 появились concepts, coroutines и ranges — так что Rust не единственный, кто умеет в модные фичи. 😏
Ответить | Правка | Наверх | Cообщить модератору

	53. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Вася Пупкин (?), 04-Апр-25, 02:30
	как же жирно, наш адреналиновый друг.. очень надеюсь что это троллинг >Производительность? В C/C++ компиляторы десятилетиями оптимизируют код так, что Rust только снится. изучи немного как работает шланг и llvm. и заодно посмотри сколько проблем в нем было найдено благодаря строгости раста, фиксы которых кстати положительно сказались и на плюсах >P.S. А ещё в C++20 появились concepts, coroutines и ranges — так что Rust не единственный, кто умеет в модные фичи. 😏 а как на счет модулей, безопасных макросов адекватного тулинга? как тебе такое, ИлонМаск?
	Ответить | Правка | Наверх | Cообщить модератору

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

	170. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+4 +/–
	Сообщение от morphe (?), 04-Апр-25, 11:27
	noalias, llvm атрибут имеющий семантику подобную restrict из C В Rust несколько лет включали и выключали его использование, потому что в llvm он был очень корявым и вызывал слишком много мискомпиляций, которые в C/C++ было очень сложно воспроизвести из-за редкого использования restrict, в отличии от Rust, где noalias стоит везде по умолчанию. Благодаря Rust в llvm исправили кучу багов с ним связанных, установили для него полноценную семантику, и сейчас думают о разделении его на несколько более специфичных атрибутов.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 14:12
	> А вот в C и C++ мы живём по-настоящему Расскажи это людям пишущим на ассемблере
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	393. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Страдивариус (?), 04-Апр-25, 20:45
	Конечно, толстенько ты накинул. Но как чел, который пишет на современных плюсах и на расте, готов подискутировать серьезно. На текущий момент могу утверждать, что в целом код на расте пишется быстрее. Однако есть штучки, которых не хватает в расте из крестов. Главное чего мне не хватает - специализация generic'ов. Прям вообще для меня жопа без неё. Нет нормальных реализаций аналогов Boost.MultiIndex (нет, crate multi_index_map - и близко не то). Макросы в расте творят чудеса, плюсам, конечно, не хватает такого мощного инструмента (нет, плюсовый препорцессор - это детская поделка, если сравнивать с растовым).
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

17. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
Сообщение от Аноним (17), 04-Апр-25, 00:01
Отлично, после создания спецификации легко можно сделать удобоваримый синтаксис с человеческим лицом поверх раста.
Ответить | Правка | Наверх | Cообщить модератору

	24. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от НяшМяш (ok), 04-Апр-25, 00:12
	Скриптоязыков поверх раста написано уже такое количество, что в опеннет не влезет. Только толку от них.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (17), 04-Апр-25, 00:16
	Можно сделать для себя любимого. А если тебе не зайдёт твои проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+9 +/–
	Сообщение от Аноним (38), 04-Апр-25, 01:25
	(после (создания спецификации)        (легко)   (можно (сделать           ((удобоваримый) синтаксис)           (с             (человеческим) лицом             (поверх))))) Починил.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	54. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+8 +/–
	Сообщение от Вася Пупкин (?), 04-Апр-25, 02:31
	"Лисп как язык не имеет синтаксиса - вы просто сразу пишете аст дерево и компилятору от этого легче жить. вам на самом деле тоже, но понимаете вы это не сразу" (ц)
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Аноним (38), 04-Апр-25, 03:52
	Шутка в том, что изначально планировалось к лиспу по завершении разработки компилятора приделать "препроцессор", который получал бы на вход алголо-подобный синтаксис а на выходе выдавал такое вот аст-дерево со скобками (то, что предложил аноним выше для раста). Но когда разработка подошла к концу, выяснилось, что все уже привыкли писать прямо так и это не особо трудно, так что алголо-подобный синтаксис оказался не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

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

	397. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Ан Оним (?), 04-Апр-25, 21:06
	Такой язык был - R-Lisp. Лисп с алголовским синтаксисом.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	309. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 16:31
	И какой простор для метапрограммирования это открывает. (foo a b c) это вызов функции, а `(foo a b c) это просто тип данных список. Сравните с обычным вызовом foo(a, b, c) и скажите кто говорит что в лиспе больше скобочек. Можно таскать аргументы от функции отдельно и подставлять нужную функцию по условию. И вообще построить поверх любой DSL синтаксис с любым синтаксисом. Так же объектная система на Lisp с поддержкой мультиметодов появилась задолго до мейнстримных ООП языков. То есть можно писать как в объектом, так и в функциональном стиле.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	323. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (323), 04-Апр-25, 16:51
	> кто говорит что в лиспе больше скобочек Наверное вот эти, которые вместо (defun f ()   (let ((a 10)         (b 20))     (+ a b))) пишут int f () {     int         a = 10,         b = 20;     return a + b; }
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 19:55
	Да так действительно лучше addEventListener("click", function (e) {   setTimeout(function() { console.log(); }) }) Особенно мне нравятся }) }) в конце.
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 20:03
	Справедливости ради никто не заставляет их писать в одну строку Можешь спустить на следующую и IDE сама выставит отступы. Если бы обработчик был чуть больше чем одна строка, то так наверное и надо было сделать.
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 23:42
	Перенести можно. А вот так бы это выглядело в lisp синтаксисе (add-event-listener "click"   (lambda (e)     (set-timeout       (lambda ()         (console-log))))) Кого-то может испугать количество скобочек в конце. Но, во-первых, они вставляются одним хоткеем, и подсветка парности в редакторе есть. Во-вторых, если посчитать, то количество ровно один в один совпадает с примером выше. В-третьих, все скобочки одинакового типа, они не перемежаются друг другом, не нужно после некоторых ставить то запятую, то точку с запятой.
	Ответить | Правка | Наверх | Cообщить модератору

	414. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (414), 04-Апр-25, 23:51
	Минус шесть скобок. Держи. addEventListener("click", e =>     setTimeout(() => console.log()) ); И конечно, юзеру удобнее, когда синтаксис есть. Если ему не надо постоянно в AST ковыряться. Чтобы писать математику на лиспе, надо отрастить стек? У человека нет такого органа.
	Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

	422. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 05-Апр-25, 01:50
	На lisp можно создавать новый синтаксис не изменяя ядро языка. Создаём макрос, который будет преобразовывать (e) => (body) к (lambda (e) (body)). И не нужно ждать 10 лет пока в язык добавят стрелочные функции. И вообще реализовать любой DSL, хочешь css правила объявляй, хочешь html формируй, не нравится префиксное сложение, поменяй на инфиксное. Что-то подобное кстати неплохо разработали в Kotlin, где можно реализовывать свои DSL строя свой синтаксис.
	Ответить | Правка | Наверх | Cообщить модератору

	423. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (414), 05-Апр-25, 02:23
	> На lisp можно создавать новый синтаксис "Any sufficiently complicated Lisp program will contain an ad-hoc, bug-ridden and slow implementation of half of mainstream programming languages and their standard libraries"
	Ответить | Правка | Наверх | Cообщить модератору

	434. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (434), 05-Апр-25, 04:41
	addEventListener("click", e =>     setTimeout(() => console.log()) ); Ну не правда же. Ваш код - аналог addEventListener("click", (e) => {   return setTimeout(() => {     return console.log();   }); }); а не продемонстрированного анонимом addEventListener("click", function (e) {   setTimeout(function() {     console.log();   }); }); Да и this внутри вашего обработчика будет не такой, как внутри оригинального варианта. Конкретно в этом случае некритично, но в облее общем может быть важно. > удобнее, когда синтаксис есть Хочется согласиться с вами, но миллионы современных программистов и яваскрипт превращают в лисп, заменяя человеческую/императивную итерацию на всякие функциональные forEach/map/filter и добавляя свои методы. Так что да, "удобнее, когда синтаксис есть", но в том же яваскрипте сейчас принято делать не "как удобнее", а "как в лиспе".
	Ответить | Правка | К родителю #414 | Наверх | Cообщить модератору

	337. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 17:42
	>И какой простор для метапрограммирования это открывает Это конечно хорошо, но проблема в том, что в этом нетипизированном месиве почти нереально разобраться. >Можно таскать аргументы от функции отдельно и подставлять нужную функцию по условию Возьмём нормальный язык, то есть Ocaml: # String.concat;; - : string -> string list -> string = <fun> Сразу понятно, сколько у функции аргументов, какой у них тип. Делаем частичное применение String.concat " " string list -> string = <fun> Опять же, всё на месте, ничего не потерялось. Что будет в лиспе после пары таких трюков? Никто, даже автор через пару месяцев, не скажет, что там происходит. И если в условном питоне сложно разобраться только из-за динамической типизации, то в лиспе ко всему этому добавляются прелести с метапрограммированием
	Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

	372. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 19:30
	>в этом нетипизированном месиве почти нереально разобраться В те времена язык с динамической типизацией, сборщиком мусора и REPL это была вершина мастерства. То есть по реализации примерно как питон, который сейчас занимает первое место по популярности. Потому что это в первую очередь функциональны язык. Как например haskell где типизация соблюдается, но и не нужно перечислять все аргументы f1 = (+ 3). То есть на lisp это будет в таком стиле (setf my-concat (partial #'string-join :separator " ")). Да ещё в нём есть кейворды, такого в других языках не встречается.
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 19:40
	>В те времена язык с динамической типизацией, сборщиком мусора и REPL это была вершина мастерства Вот что меня удивляет, так это любовь в IT сфере к устаревшим решениям. Вот интересно, как бы отнёсся человек к предложению писать на язык допетровских реформ?
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Ан Оним (?), 04-Апр-25, 21:10
	Алгоритмические языки (и другие формальные нотации, допустим, математическая нотация) не устаревают
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 22:28
	Ещё как устаревает. Было время, когда не было арабских(то есть индийских) цифр, а были римские. Было время, когда не было знаков препинаения, авесьтекстписалсяводномрегистребезпробелов. Сейчас есть гораздо более удобные вещи, чем динамическая типизация
	Ответить | Правка | Наверх | Cообщить модератору

	433. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (434), 05-Апр-25, 04:30
	> > язык с динамической типизацией, сборщиком мусора и REPL > любовь в IT сфере к устаревшим решениям Простите, а вы что из перечисленного считаете устаревшим? 90% современных языков поддержимают минимум две из трёх перечисленных возможностей. Если не считать именно  устаревшие компилируемые языки.
	Ответить | Правка | К родителю #377 | Наверх | Cообщить модератору

	445. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 05-Апр-25, 14:35
	Динамическую типизацию. Это может и смотрелось хорошо в прошлом, но во-первых есть семейство ML подобных языков, типа Ocaml и Haskell, а во-вторых, даже до разработчиков на динамически типизированных языках дошло, и они стали добавлять типизацию в php, python, ruby, в js в виде ts.
	Ответить | Правка | Наверх | Cообщить модератору

	432. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (434), 05-Апр-25, 04:27
	> есть кейворды, такого в других языках не встречается В яваскрипте есть Symbol(), это не те же кейворды но в более ущербном (как это принято в яваскрипте) виде?
	Ответить | Правка | К родителю #372 | Наверх | Cообщить модератору

30. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+4 +/–
Сообщение от Аноним (30), 04-Апр-25, 00:32
Язык для всех кто любит страдать.
Ответить | Правка | Наверх | Cообщить модератору

	42. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+8 +/–
	Сообщение от илонмаск (?), 04-Апр-25, 01:37
	Так это про СИ++
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (111), 04-Апр-25, 07:05
	> поддержка приведения (upcast) типажей к базовому супертипажу (supertrait), т.е. появилась возможность прямого преобразования ссылки на объект типажа в ссылку на объект супертипажа без необходимости создания специального метода в типаже, возвращающего ссылку на супертипаж. Как же мне этого не хватало в C!
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Аноним (275), 04-Апр-25, 08:44
	> Как же мне этого не хватало в C! Вот именно! Понапридумывали всякой дичи вместо православного пердолинга с void*
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–3 +/–
	Сообщение от Аноним (260), 04-Апр-25, 14:53
	Все думают cast это что-то магическое, кроме простой интерпретации структур данных. В ассемблере же есть просто mov eax,[eax+..] несколько раз c подстановкой нужных смещений. И это и есть реальность.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 15:00
	> Все думают cast это что-то магическое, кроме простой интерпретации структур данных. > В ассемблере же есть просто mov eax,[eax+..] несколько раз c подстановкой нужных смещений. > И это и есть реальность. Это понятно. Тут скорее вопрос к очевидности. Типа "неявно кастанул int64 к int16". В одном языке оно молча прожует и попортит данные. А в другом будет настойчиво требовать сделать это видным в коде.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 15:55
	Так это проблема программиста. Неявности надо избегать, иначе не только другой не поймет, но и сам забудешь через неделю.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 16:07
	> Так это проблема программиста. Неявности надо избегать, иначе не только другой не поймет, но и сам забудешь через неделю. А еще проблема электрика, что у нас все провода одного цвета, и монтажника, что у нас болты прочностью 12.9 маркируются как и 5.6 и водителя, что светофоры убрали, пусть по сторонам головой крутит, и врача, ну подумаешь монитор жизнедеятельности не пищит и не предупреждает что пациент вот-вот коней двинет... Просто надо быть внимательнее и все будет хорошо. ps на досуге подумай почему во время предполетной подготовки проходят по списку и отмечают галочками проверенные пункты.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 16:15
	Типичная отмазка исполнительного программиста перед менеджером. P.S. бывают криминальные случае, когда чтобы скрыть свою халатность ломают систему оповещения. Мол, система оповещения не пиликала.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 17:15
	> Типичная отмазка исполнительного программиста перед менеджером. Это не отмазка, а нормальная практика практически во всех областях деятельности человека. Для станков делают щитки, предохранители, разнесенные кнопки, чтобы шаловливые ручки прессом не придавило. Для авто делают камеры, датчики слепых зон, добавляют антисон. Для сотрудников - регламентируют время работы (чтобы водилы за рулем не засыпали), ставят всякие тахографы, продумывают эргономику и системы хранения, иногда даже компьютеризированные, чтобы меньше было шансов нафакапить при сборке, всякие валидаторы форм и так далее. Про опасные вещи вроде огнестрела вообще молчу - так 3 предохранителя уже давно не что-то уникальное. Но только в пограммисты считают себя самыми умными и продолжают факапить в одних и тех же местах!
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 17:57
	Стоп. Изначально я говорил, что надо избегать неясности. И надо указывать явно, что хочет программист. Это надо расценивать как мера предосторожности. Вы же сейчас меня обвиняете, что я против мер предосторожности. Ловко.
	Ответить | Правка | Наверх | Cообщить модератору

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

	411. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Витюшка (?), 04-Апр-25, 23:28
	Не получился. Его пассаж - "делай всё явно, и Rust не нужен".
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (275), 04-Апр-25, 15:07
	> Все думают cast это что-то магическое, кроме простой интерпретации структур данных. > И это и есть реальность. Какая ирония... Реальность в том, что ты типичный сишник, не слышавший про strict aliasing.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	298. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 15:51
	Реальность в том, что в С интервлияние неправильной интерпретации видны сразу, а в C++ Вы настолько запутались в иерархиях, что это не видно и превращается в скрытую проблему.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (260), 04-Апр-25, 16:20
	Ассемблер тоже не слышал про модные слова. Есть адрес и он одинаков, к примеру. в указателе буфера и указателе на структуру над этим буфером. И последствия как бы очевидны. Используйте union
	Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

	56. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Вася Пупкин (?), 04-Апр-25, 02:32
	только пока не приручишь борроу-чекер
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	78. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–4 +/–
	Сообщение от wyry (ok), 04-Апр-25, 04:54
	А в итоге не приручишь, т.к. в простых задачах он не слишком то нужен, а в сложных алгоритмов придётся всё равно всё разруливать. Это кстати также объясняет практически полное отсутствие некоторых типов ПО на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 05:31
	> А в итоге не приручишь, т.к. в простых задачах он не слишком > то нужен, а в сложных алгоритмов придётся всё равно всё разруливать. > Это кстати также объясняет практически полное отсутствие некоторых типов ПО на > Rust. Я тоже об этом думал. Хорошо бы отдельное исследование почитать по данному вопросу. Возможно раст временно займёт какую-то свою нишу, но не более. Что-то похожее произошло с чисто функциональными языками программирования, тоже из-за фундаментальных ограничений.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (414), 04-Апр-25, 06:20
	> Возможно раст временно займёт какую-то свою нишу, но не более. На очередные 50 лет, но не более. Системные языки. Языки без сборки мусора. Никто здесь не собирается теснить Rust. C и C++ озабочены тем, как бы им заморозиться и поменьше менять. Сишники идею плавного развития отвергли ещё в момент создания C++, теперь поедают Rust. Остальным языкам денег не хватит, чтобы распиариться.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (88), 04-Апр-25, 06:48
	Так пиар это для продаж Кока Колы, ширпотреба хорошо работает. А там где собираются интеллектуалы, инженеры - на пиаре далеко не заедешь. Вам уже тысячу раз говорили - синтаксис непричёсаный (такой же уродский брейнфак как у "современных" плюсов, но на плюсах хотя бы можно всё причесать по своему, не использовать stl и поэтому плюсы остаются жизнеспособными), компилится долго (в то же время в си++ если не увлекаться шаблонной магией - всё в порядке), бинарники раздутые, свистопляска с зависимостями сомнительного качества, боров накладывает серьёзные ограничения на больших проектах, сторонних библиотек кот наплакал, постоянные изменения эдишенов - это дорога в ад с потенциальными несовместимостями в кодовой базе. Короче, пока так себе "конкурент" плюсам.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (414), 04-Апр-25, 07:32
	> Так пиар это для продаж Кока Колы, ширпотреба хорошо работает. А там где собираются интеллектуалы, инженеры - на пиаре далеко не заедешь. А что эти интеллектуалы собрались кушать, программируя на малоизвестным языке с 0 вакансий? Если корешки в тундре, то они для общества мертвы, вместе с их малоизвестным языком. Вместо языка программирования можно любой инструмент подставить. Это так не работает. Надо вкладываться и создавать экосистему почти для всего, надо как-то дорастать до состояния too big to fail. Если за языком стоит гугл или хотя бы майкрософт или эпл или хотя бы гугловская прослойка вроде мозиллы, то они своими деньгами и интересами обеспечивают языку будущее. А если стоит один человек, то он же умереть может. Даже если человека два - вдруг один опять жену убьёт, а второй пойдёт плохой дорогой (хуа-вей)? Рискованная инвестиция получается. > Вам уже тысячу раз говорили - синтаксис непричёсаный Не нам. Им. И за причёсанность синтаксиса деньги не платят. Это к другим интеллектуалам, в театр, в литературный кружок.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 07:50
	>> Так пиар это для продаж Кока Колы, ширпотреба хорошо работает. А там где собираются интеллектуалы, инженеры - на пиаре далеко не заедешь. > А что эти интеллектуалы собрались кушать, программируя на малоизвестным языке с 0 > вакансий? Если корешки в тундре, то они для общества мертвы, вместе > с их малоизвестным языком. Вместо языка программирования можно любой инструмент подставить. Почитай, к примеру, историю PHP. Там не было супер-пиара. Чувак сделал для себя, просто чтоб было удобно, потому что Перл всем осточертел. И не поверишь - взлетело. Да, криво, но потом подтянулись другие гениальные ребята и допилили до приемлемого уровня, на котором даже цукер ваял свою мордокнигу. > Это так не работает. Надо вкладываться и создавать экосистему почти для всего, > надо как-то дорастать до состояния too big to fail. Если за > языком стоит гугл или хотя бы майкрософт или эпл или хотя > бы гугловская прослойка вроде мозиллы, то они своими деньгами и интересами > обеспечивают языку будущее. А если стоит один человек, то он же > умереть может. Даже если человека два - вдруг один опять жену > убьёт, а второй пойдёт плохой дорогой (хуа-вей)? Рискованная инвестиция получается. Ну-ну. Создать г0вн0поделие и с помощью пиара прокладывать ему дорогу. Небось эффективные менеджеры подсказали? Это действительно работает, но только до определенного предела. Дальше - глухая стена, которую вы наблюдаете в том числе среди участников данного ресурса. >> Вам уже тысячу раз говорили - синтаксис непричёсаный > Не нам. Им. > И за причёсанность синтаксиса деньги не платят. Когда сам язык мешает в работе и замедляет процесс реализации (вместо того чтобы упрощать - всё переусложняет, т.е. приучает программистов к оверинжинирингу), величина денежных расходов - вполне ощутима для бизнеса.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (167), 04-Апр-25, 11:18
	Имею стойкое ощущение что за Ржавчину топят яваскриптёры и любители Node.js а этих к интеллектуалам никак не определишь.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

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

	222. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анон1110м (?), 04-Апр-25, 13:19
	Они просто не хотят мараться об это.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 13:43
	Двоечники тоже не хотели мараться о математике, русском языке...
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 11:46
	> Вам уже тысячу раз говорили чушь) > - синтаксис непричёсаный (такой же уродский брейнфак как у "современных" плюсов, но на плюсах хотя бы можно всё причесать по своему, не использовать stl и поэтому плюсы остаются жизнеспособными), У дидов мозги не могут еще пару значков распознать? Советы выкинуть stl тоже классный) > компилится долго (в то же время в си++ если не увлекаться шаблонной магией - всё в порядке), А есть большие проекты С++ без шаблонов? Раст не компилируется долго, а проверяет чего там мясной мешок понаписывал. > боров накладывает серьёзные ограничения на больших проектах, Что-то гуглу это не мешает. Или андроид это уже не достаточно большой проект? > сторонних библиотек кот наплакал, Это все потому что ты не написал их) > постоянные изменения эдишенов - это дорога в ад с потенциальными несовместимостями в кодовой базе. Эдишены выходят раз в 3 года. Что странно С++ бывает C++11, C++14, C++17, C++20, C++23... Улавливаешь закономерность)? > Короче, пока так себе "конкурент" плюсам. Настолько, что новый код в андроиде пишут на нем, вместо плюсов)
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	306. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 16:21
	Нормальный синтасис, а не где есть 15 способов создать объект и ещё 70 способов выстрелить себе в ногу. C++ настолько раздутый стандарт и туда всё продолжают добавлять и добавлять. Вот когда создадут надмножество без шаблонов и кучи разных способов написать одно и тоже, тогда и поговорим. Из неудобного синтасиса в Rust там только лайфтаймы, но они не каждый раз нужны. >компилится долго Так почему вы не включаете сюда санитайзеры. Ведь без них не обойдётся сборка большего проекта. >бинарники раздутые Пиши с [no_std] без стандартной библиотеки и будут тебе не раздутые. Если уже Rust подходит для Embedded, то значит никаких проблем с размером бинарников нет. >зависимостями сомнительного качества, сторонних библиотек кот наплакал Так кто тебя заставляешь устанавливать с cargo сомнительного качества? Устанавливай из своего репозитория, устанавливай из своего git, пиши свои велосипеды, подключай проверенные сишние через обёртку. >постоянные изменения эдишенов - это дорога в ад с потенциальными несовместимостями в кодовой базе Тогда расскажи как у тебя всё совместимо между C++17 и C++20. О каких постоянные изменениях в эдишенах ты говоришь, если они выходят раз в 3 года, так же как c++.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	146. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Соль земли (?), 04-Апр-25, 10:13
	Чтобы научить их перестать страдать.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	153. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 04-Апр-25, 10:38
	Не всегда процесс думания, к чему вы, похоже, не привыкли - это страдание, далеко не всегда. Часто на выходе много  допамина, который создаёт ощущение счастья и крутости.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

46. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
Сообщение от Нуину (?), 04-Апр-25, 01:45
Спецификация -- это хорошо. Возможно после этого появятся альтернативные реализации.
Ответить | Правка | Наверх | Cообщить модератору

	112. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (111), 04-Апр-25, 07:06
	> Возможно после этого появятся альтернативные реализации Здоровая идея. Фрагментация экосистемы by design.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Bottle (?), 04-Апр-25, 07:19
	Фрагментация экосистемы тоже разная бывает. Люди явно не от хорошей жизни вносят изменения, случаи намеренного саботажа (Microsoft Java, он же C#) - единичные.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (111), 04-Апр-25, 07:23
	> Microsoft Java, он же C# Java от Microsoft, он же Visual J++. Ох уж эти неофиты.
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 16:38
	>Ох уж эти неофиты. Любой неофит мгновенно поймёт свою ошибку, попытавшись собрать java код с помощью c#. Так что тут нужно другое словно
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (-), 04-Апр-25, 07:22
	> Здоровая идея. Фрагментация экосистемы by design. Пример C/C++ показал что сие неплохо работает. А когда все решает 1 производитель 1 тулчейна - можно случайно обнаружить что кое-чот дверью прищемило, а плана на этот случай почему-то нет.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	123. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (111), 04-Апр-25, 07:26
	Это был сарказм.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 11:14
	> Пример C/C++ показал что сие неплохо работает. Угу, шикарно работает. Есть три основных компилятора + еще кучка менее распространенных. А потом внезапно оказывается что одну софтину ты можешь собрать только gcc и нужно тыщщи человекочасов чтобы побороть EEE и заставить ее компилиться шлангом, а что-то наоборот только шлангом и у авторов нет планов поддерживать gcc.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	194. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (189), 04-Апр-25, 12:11
	И это нормально. Каждый разработчик ставит цели и приоритеты. Есть те, кто пишет программы рассчитанные на работу в новейших дистрибутивах linux и древних никсах. А есть те кто не может на такое рассчитывать. Потому как ресурсы не безграничны.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (321), 04-Апр-25, 16:50
	Пруфов у тебя, разумеется, не будет? Куча софта в BSD компилируется вместо gcc с помощью clang. Да-да, того самого, который изначально под Linux и gcc был. OpenMandriva - первый из Linux дистрибутивов который стал ядро и софт собирать с помощью clang. Может будем смотреть фактам в лицо?
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	336. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 17:41
	> Пруфов у тебя, разумеется, не будет? Конечно будут. Хромиум bbs.archlinux.org/viewtopic.php?id=255805 - челу пришлось даунгрейдится до гцц9 issues.chromium.org/issues/380211803 issues.chromium.org/issues/42204388 ФФ bugzilla.mozilla.org/show_bug.cgi?id=1711525 mail-archive.com/gcc-bugs@gcc.gnu.org/msg857555.html И в обратную сторону - есть ядро, которое было прибито к ГЦЦ и гнутым экстеншнам годами. Смогло оно билдится шлангом только вроде в 2011 году. И потом еще его N лет доводили до ума и правили баги. > Может будем смотреть фактам в лицо? А давай! У тебя есть clang-specific attributes, есть gcc-specific attributes, есть еще специфические для MSVC и скорее всего есть и для других вроде интелового и прочих платных. И вот фиг ты скомпилишь код под других компилятором.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (-), 04-Апр-25, 07:21
	> Спецификация -- это хорошо. Возможно после этого появятся альтернативные реализации. Gccrs уже так то - разрабатывают и довольно активно.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

60. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от Аноним (60), 04-Апр-25, 02:58
Плюс одна итерация бутстрапа(самосборки). Хорошо, что сишный компилятор раста mrustc дошел до версии 1.74. не придется с версии 1.54 бутстрапить. В любом случае слишком часто мажорные версии выходят, практически каждый месяц.
Ответить | Правка | Наверх | Cообщить модератору

	130. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (111), 04-Апр-25, 08:33
	> В любом случае слишком часто мажорные версии выходят, практически каждый месяц. Значит, стараются люди. У меня в проекте за полгода 7 мажорных версий вышло. Только задуматься - полгода назад еще ничего не было.
	Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–3 +/–
Сообщение от ostov (?), 04-Апр-25, 03:04
Мне кажется, что при создании языка **СНАЧАЛА** пишется спецификация, а уже потом реализации. Ох уж этот новый мир «языков-брендов»...
Ответить | Правка | Наверх | Cообщить модератору

	64. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (64), 04-Апр-25, 03:22
	>при создании языка **СНАЧАЛА** пишется спецификация, а уже потом реализации Lol. Такого не было никогда и ни с кем. Единственный обратный пример это ALGOL 68.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (111), 04-Апр-25, 07:08
	Ну почему? В науке такой подход сплошь и рядом. Сначала изобрели односторонние функции, потом шифрование на их основе.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Минона (ok), 04-Апр-25, 10:17
	Ты прогуливал уроки истории. Вирт все свои языки именно так и создавал -- сначала формальное описание, потом воплощение в коде.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	192. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 12:09
	>Вирт все свои языки именно так и создавал -- сначала формальное описание, потом воплощение в коде. Угу, и получились отличные учебные языки для введения в программирование. Правда, ленивые студенты потом пытались продолжать в проде, но дальше примитивных гуйных "магазинов" не пошло.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (321), 04-Апр-25, 12:55
	Modula в глонасс используется. Ada в критичном ПО. Есть ли в rust формальная верификация? Нет. А в Ada есть.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (241), 04-Апр-25, 13:59
	> Modula в глонасс используется. В глонассах могут хоть брейнфак использовать)) > Ada в критичном ПО. Не Ada, а ее подмножество SPARK. Вот в нем есть верификация. > Есть ли в rust формальная верификация? Нет. Пока нет. Но раст уже можно использовать в автомотив (ISO 26262, ASIL-D), пром (IEC 61508, SIL4) и  медицине (IEC 62304, SIL 4). "Ferrocene квалифицирован по ISO 26262 и IEC 61508, что позволяет разрабатывать приложения на уровень безопасности SIL4 (например, уровень безопасности пассажирского движения на железной дороге)" Ну и не везде нужна эта формальная верификация. Ты не будешь формально верифицировать 99% софта, который пишут на расте. Просто потому что это слишком дорого.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (321), 04-Апр-25, 16:48
	> В глонассах могут хоть брейнфак использовать)) К чему эта фраза? По факту не могут. Пишите чушь для красного словца.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 17:12
	>Есть ли в rust формальная верификация Проект RustBelt начат ещё в 2015 по верификации базовых структур без unsafe и выпустили несколько научных статей по результатам. Вот буквально недавно в конце 2024 Rust Foundation вместе с AWS начали верификацию всей стандартной библиотеки включая все unsafe функции.
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	272. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Минона (ok), 04-Апр-25, 14:58
	> Угу, и получились отличные учебные языки для введения в программирование. Правда, ленивые > студенты потом пытались продолжать в проде, но дальше примитивных гуйных "магазинов" > не пошло. Щаз... Oberon -- система управления дорожным движением в Цюрихе. Component Pascal -- система управления каскадом ГРЭС на Амазонке. Modula-2 -- ПО для спутников. Oberon-07 -- для программирования микроконтроллеров. Pascal -- первая версия Windows =)
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	370. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Аноним (-), 04-Апр-25, 19:19
	> Щаз... Вы же понимаете, что предоставляя список исключений, только подтверждаете оригинальный тезис? Потому что перечислять все что написано на Ада только для авиа - уже замахаешься. А если вообще все... то как-нибудь сами :)
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 10:38
	>>при создании языка **СНАЧАЛА** пишется спецификация, а уже потом реализации > Lol. Такого не было никогда и ни с кем. > Единственный обратный пример это ALGOL 68. Неа. Например АДА - сначала написали требования, потом несколько итераций уточнений. Потом объявили конкурс на разработку. Более того, специально закопирайтили чтобы нельзя было какие-то полуфабрикаты называть так. Для того чтобы называться "компилятор АДА" нужно пройти тесты: 1000+ тестов, один провалил - идешь лесом. Это тебе не компиляторы для дыряшки "это я реализую, а это не поддерживаю, а тут не знаю как два числа без UB сложить")
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	195. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 12:12
	>Например АДА - сначала написали требования, потом несколько итераций уточнений. >Потом объявили конкурс на разработку. Угу, и программируют на этом только из-под палки. Никто не любит Аду ☺. А Rust и Go приносят смех и радость людям.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Нуину (?), 04-Апр-25, 15:16
	> А Rust и Go приносят смех и радость людям. Вот я и смотрю ты на фото такой счастливый...
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (189), 04-Апр-25, 12:16
	> Это тебе не компиляторы для дыряшки "это я реализую, а это не поддерживаю, а тут не знаю как два числа без UB сложить") Для особо одаренных. На разных архитектурах переносимо проверка не реализуется. Так что возможность "складывать" безопасно отдельно. Возможность отработать много "складываний" а потом узнать, достоверно ли - отдельно. Ну и возможность просто "складывать" отдельно. Если у вас не так - то сразу себе кучу платформ отрываете.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	204. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 12:29
	> Для особо одаренных. На разных архитектурах переносимо проверка не реализуется. Очень печально. Для этих архитектур) > Если у вас не так - то сразу себе кучу платформ отрываете. Огласите весь список, пожалуйста! (с) Какие ныне существующие платформы отличаются от поведению?
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 17:46
	>Если у вас не так - то сразу себе кучу платформ отрываете. Значит ради какой-то экзотики в микроконтроллерах или давно ушедших архитектурах, сейчас в 2025 году при программировании исключительно под десктопы/серверы предлагается терпеть всё это непотребство? А то вдруг кто-то nginx на микроконтроллере запустить попытается, а там mmu(или ещё чего) нет?
	Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

	440. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Омномним (?), 05-Апр-25, 11:38
	при этом для всякой экзотики мат. операции для float & double реализовали софтово, и ниче 😀
	Ответить | Правка | Наверх | Cообщить модератору

	417. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (414), 05-Апр-25, 00:24
	Для одарённых ещё более - если на разных архитектурах что-то различается, то для этого можно использовать implementation-defined и unspecified. "EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right." А сишный UB - это такая штука, из допущения об отсутствии которой отталкивается оптимизатор. "Допустим, что знаковых переполнений в программе нет (программист их везде избежал)". https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...
	Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

	437. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 05-Апр-25, 10:54
	> Например АДА - сначала написали требования, потом несколько итераций уточнений. Требования с уточнениями -- это не спецификация языка. Они же написали требования, а потом начали смотреть удовлетворяют ли существующие языки этим требованиям. Не нашли не одного, и > объявили конкурс на разработку.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	68. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (96), 04-Апр-25, 03:33
	> при создании языка **СНАЧАЛА** пишется спецификация Сначала фигня, изобретение. А потом автор придумывает где и как это изобретение применять, не наоборот.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	127. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (127), 04-Апр-25, 08:07
	> Мне кажется, что при создании языка **СНАЧАЛА** пишется спецификация, а уже потом реализации. Тебе действительно кажется.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

84. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–3 +/–
Сообщение от Аноним (-), 04-Апр-25, 05:25
>Дополнительно можно отметить, что компания Ferrocene передала сообществу спецификацию на язык Rust (FLS - Ferrocene Language Specification Ferrocene, как коммерческая компания должна знать, что языком программирования Rust может считаться только компилятор разрабатываемый самим сообществом Rust. Все остальные будут считаться левыми поделиями. У Rust нет международного ISO Стандарта. Так гласил лицензия и торговая марка на имя Rust programming language.
Ответить | Правка | Наверх | Cообщить модератору

	116. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Bottle (?), 04-Апр-25, 07:17
	*Современные* ISO стандарты - это элитная туалетная бумага, которой обладают только те, кто её пишёт. Говорить о важности стандартов от авторов стандартов на акупунктуру - себе дороже. Это сборище бумагошлёпов, цель которых - продать документ. Здесь же даётся открытая спецификация, хорошо, если ей будут соответствовать.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (260), 04-Апр-25, 16:37
	Стандарт нужен не создателю, стандарт нужен потребителю. Как создатель, я не заинтересован ограничивать себя соблюдением стандарта.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

100. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–8 +/–
Сообщение от Аноним (64), 04-Апр-25, 06:11
На языке без сборщика мусора невозможно писать безопасный код. Это просто бессмысленный "когнитивный налог" на программиста, который оставляет меньше "когнитивного бюджета" для избежания логических ошибок.
Ответить | Правка | Наверх | Cообщить модератору

	158. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от Прохожий (??), 04-Апр-25, 10:56
	На языке без сборщика мусора возможно писать безопасный код. И доказательство этому язык Rust, а также отчёты таких фирм-лидеров на рынке, как Microsoft, Google, Cloodflare, Dropbox, Discord, Amazon. Однако следует заметить, что Rust не даёт гарантию на отсутствие всех возможных типов ошибок, такая гарантия предоставляется только для ошибок определённого класса. >Это просто бессмысленный "когнитивный налог" на программиста, который оставляет меньше "когнитивного бюджета" для избежания логических ошибок. Опыт указанных выше фирм показывает, что ограничения, накладываемые компилятором Rust, имеют большой и значимый смысл. Количество ошибок в исходном коде уменьшилось, качество программирования значительно выросло, производительность труда тоже выросла. Всё перечисленное доказывает, что ваше мнение умозрительное, то есть не основано ни на чём.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (88), 04-Апр-25, 11:19
	>>Это просто бессмысленный "когнитивный налог" на программиста, который оставляет меньше "когнитивного бюджета" для избежания логических ошибок. > Опыт указанных выше фирм показывает, что ограничения, накладываемые компилятором Rust, > имеют большой и значимый смысл. Количество ошибок в исходном коде уменьшилось, > качество программирования значительно выросло, производительность труда тоже выросла. > Всё перечисленное доказывает, что ваше мнение умозрительное, то есть не основано > ни на чём. Если бы упомянутого "когнитивного налога" не было, то и Си, и Джавы бы никто не изобретал. Писали бы на асме. Rust и "модернистский" стиль плюсов - своими бессмысленными переусложнениями на ровном месте как бы возвращают нас опять ближе к асму, когда "когнитивного бюджета" не хватает для быстрого прототипирования, быстрого понимания кода (как это можно делать на простых языках типа питона итд). Надеюсь вы уловили смысл. Но вы вместо логики для признания очевидного - похоже включаете мантру: не верь своим очам, верь корпорастическим речам.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 12:23
	Если вы говорите о "бессмысленных переусложнениях" в тщательно продуманных языках программирования, то вы, возможно, что-то не поняли? Или вы думаете, что кто-то просто по приколу наворачивает конструкты? ☺☺☺
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (88), 04-Апр-25, 12:42
	> Если вы говорите о "бессмысленных переусложнениях" в тщательно продуманных языках программирования, > то вы, возможно, что-то не поняли? Или вы думаете, что кто-то > просто по приколу наворачивает конструкты? ☺☺☺ Ага, наверное не понял зачем переусложнять. Как говорит Кен Томпсон в таких случаях: "наверное, я слишком стар" )))
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (275), 04-Апр-25, 13:28
	> Ага, наверное не понял зачем переусложнять. Так и есть. И если я тебя сейчас спрошу «покажи, как надо было сделать без этих "преусложнений"», то ты моментально сольешься.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 13:48
	Так для своей фирмы я уже сделал без переусложнений. Это моё конкурентное преимущество. А вы продолжайте уверять себя в том, что modern style - вершина прогресса. Можете считать что я "слился", меня это устраивает)
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Минона (ok), 04-Апр-25, 15:02
	> Rust и "модернистский" стиль плюсов - своими бессмысленными переусложнениями на ровном > месте как бы возвращают нас опять ближе к асму, когда "когнитивного > бюджета" не хватает для быстрого прототипирования, быстрого понимания кода (как это > можно делать на простых языках типа питона итд). Надеюсь вы уловили > смысл. Пиши на Лиспе, он простой.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	293. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 15:32
	> Пиши на Лиспе, он простой. Слишком простой, в результате чего код больших проектов становится внезапно... сложным. Задача - выбрать оптимальную "золотую середину". Дальше думайте сами.
	Ответить | Правка | Наверх | Cообщить модератору

	426. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 03:20
	>Задача - выбрать оптимальную "золотую середину" Но её нет. В том смысле, что для каждой конкретной ситуации она своя. Знаете, небось, поговорку "скорость, качество, цена - выбирай любые два"? Вот это оно.
	Ответить | Правка | Наверх | Cообщить модератору

	425. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 03:16
	>своими бессмысленными переусложнениями Они бессмысленные только для тех, кто не понимает семантику языка. >когда "когнитивного бюджета" не хватает для быстрого прототипирования, быстрого понимания кода (как это можно делать на простых языках типа питона итд). Надеюсь вы уловили смысл Дык кто лично вам запрещает использовать LLM для трактовки кода, если у вас сложности с быстрым его пониманием? Пользуйтесь благами цивилизации, это несложно. Далее, вы же не собираетесь какое-нибудь приложение, требовательное к производительности, писать на Питоне, правда? А для современных сложных приложений Си уже явно не подходит, слишком там много надо каждый раз изобретать с нуля (чем и занимаются многие программисты на этом языке) и слишком велика вероятность появления критических ошибок в коде из-за недостаточного контроля со стороны компилятора. Надеюсь, вы уловили смысл?
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	338. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 17:42
	>На языке без сборщика мусора невозможно писать безопасный код Как это вообще связанно? То есть на Си невозможно написать даже обычный безопасный хеловорд? А раз это не так, то это ложное утверждение. А уж интересно на каком языке написан сам сборщик мусора, и как оказывается написаны они на том самом "небезопасном". В Rust из-за модели владения не нужно вручную удалять переменные, то есть внешне это работает также как как код со сборщиком мусора. >который оставляет меньше "когнитивного бюджета" для избежания логических ошибок. Да вместо того проверять каждую строчку коду не вышел ли кто-то за буфер, у программиста остаётся больше времени на обработку логики.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	344. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 17:57
	>>На языке без сборщика мусора невозможно писать безопасный код > Как это вообще связанно? То есть на Си невозможно написать даже обычный безопасный хеловорд? А раз это не так, то это ложное утверждение. Ну... в каком-то смысле он прав. Если посмотреть раздел 4й стандарта про конформанс, то там сказано "используете UB - конформанс нарушается". А хеловорд это будет явно какой-то вывод. Ну или сложение двух чисел) > В Rust из-за модели владения не нужно вручную удалять переменные, то есть внешне это  работает также как как код со сборщиком мусора. В расте оно проверяется на этапе компиляции. > Да вместо того проверять каждую строчку коду не вышел ли кто-то за > буфер, у программиста остаётся больше времени на обработку логики. Зачем проверять есть можно не проверять ;) 100 раз так делал и все было нормально (с)
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 19:37
	> В расте оно проверяется на этапе компиляции. Всё так. То есть переменная удаляется при выходе из области видимости и нет необходимости вручную писать delete. Или удалиться в конце той функции в которую мы передали владение. Если мы передаёт указатель, то владение не передаётся. Всё просто как в языках со сборщиком мусора, мы просто создаём переменные когда хотим, а удаляться они сами когда рассчитает компилятор, а не когда сборщик мусора изволит запуститься. И нет вот этих споров, где не понятно кто должен очищать память библиотечная функция или вызывающий её код.
	Ответить | Правка | Наверх | Cообщить модератору

	394. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (394), 04-Апр-25, 20:57
	Не понимаю все эти наезды на указатели, адресную арифметику, так называемое UB. Все это есть особенности реализации процессора, а не прихоти создателей C, который просто адекватно отражает компьютерное железо, что и должен обеспечивать язык системного программирования. Если в вашем алгоритме сложение двух чисел может привести к UB, то может быть правильное решение не в том чтобы использовать rust, а том чтобы применить double? Чтобы поймать целочисленное переполнение в процессоре x86-84 нужно дополнительно выполнять условный оператор (jo или jno) после арифметических, что увеличивает размер программы, уменьшается скорость и время работы от батареи. В то время как FPU может самостоятельно сгенерировать прерывание в отличие от CPU. Можно ли написать уязвимый, глючный код на C? Безусловно. Но ведь можно написать и нормальный.
	Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

	407. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 22:24
	> Не понимаю все эти наезды на указатели, адресную арифметику, так называемое UB. Причем тут UB к указателям и адресной арифметике? В сишке этих UB просто море gist.github.com/Earnestly/7c903f481ff9d29a3dd1 Причем некоторые вообще дичь, напр. Signed integer overflow. Почему его не сделали implementation-defined behavior? Этому хоть было бы оправдание - на одной некроплатформе оно по-одному было реализовано, на другой - по-другому. Сейчас правда не осталось живых платформ где оно не two’s complement wrapping, но типа сишников это парит. Но само наличие UB просто нарушает конформанс всей программы! Потом шибко умные пограмисты начинают жаловаться что их код "оптимизировал" компилятор. А потому что компилятор предполагает что UB не возникнет НИКОГДА. > что увеличивает размер программы, уменьшается скорость и время работы от батареи. Сейчас 2025й год. > Но ведь можно написать и нормальный. Угу, только практически никому не удается ¯\_(ツ)_/¯
	Ответить | Правка | Наверх | Cообщить модератору

	415. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 05-Апр-25, 00:01
	Посыл вообще не про UB и переполнение интов. А про то что не нужно забывать очищать память в конце функции. Это просто удобство и 21 век уже на дворе, если компилятор за тебя может автоматически вставить там где надо free. И конечно он не допустит по недосмотру double-free или use-after-free.
	Ответить | Правка | К родителю #394 | Наверх | Cообщить модератору

105. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
Сообщение от _ (??), 04-Апр-25, 06:31
> для создания эталонной спецификации на язык Rust Неужто взрослеют?! :) Вооо - вот это уже интереснее!
Ответить | Правка | Наверх | Cообщить модератору

114. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
Сообщение от Bottle (?), 04-Апр-25, 07:13
Спецификация - это ОЧЕНЬ хорошо, будем надеяться на то, что появятся альтернативные реализации, совместимые с ней.
Ответить | Правка | Наверх | Cообщить модератору

	147. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Соль земли (?), 04-Апр-25, 10:15
	Зачем? Из Rust Foundation выгнали?
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Cucumber (?), 04-Апр-25, 10:18
	А нафига? Я просто не понимаю.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

139. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от С Software Engineer (?), 04-Апр-25, 09:33
Вчера наткунлся на такую на мой взгляд неконсистентность в дизайне: ``` let x = 1;   // non-atomic x = 2;       // doesn't compile as expected lex x : AtomicI8 = AtomicI8::new(1);  // atomic x.store(2, std::sync::atomic::Ordering::Relaxed); // compiles ``` суть странности что стандартные атомики как я понял не требуют mut чтобы изменять значение.
Ответить | Правка | Наверх | Cообщить модератору

	141. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от С Software Engineer (?), 04-Апр-25, 09:36
	Выше в коменте я опечатaлся, под `lex x` имелось ввиду `let x`
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+3 +/–
	Сообщение от palas (?), 04-Апр-25, 10:03
	Это потому, что атомики - это типы с interior mutability. Если бы store принимал &mut self вместо &self, то в них не было бы никакого смысла, т.к. &mut ссылка всегда уникальна (название может ввести в заблуждение, может лучше было бы её обозвать &uniq). Так что по сути это намеренный обход боров чекера, но при этом все инварианты сохраняются, что в RefCell/Cell, что тут, поэтому шансов попортить память нет
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	342. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 04-Апр-25, 17:49
	Всё равно эта interior mutability выглядит как костыль. Но я понимаю что без неё не обойтись. Например тот же Rc/Arc/RwLock можно клонировать и потом мутировать, но при этом он будет таким же уникальным, за счёт блокировок, а не за счёт уникальности указателя.
	Ответить | Правка | Наверх | Cообщить модератору

	391. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от morphe (?), 04-Апр-25, 20:28
	> Например тот же Rc/Arc/RwLock можно клонировать и > потом мутировать Rc/Arc не то же самое что RwLock Rc/Arc есть struct RcBox<T> {value: T, counter: Cell<usize> либо AtomicUsize} Box<RcBox<T>>, т.е значение одно аллоцировано в куче, а ссылок на него много, и есть счётчик этих ссылок, клонирование лишь создаёт ещё одну ссылку Изменять значение нельзя, чтобы значение мутировать, нужно использовать Arc<Mutex<_>> RwLock<T> же просто многопоточный аналог RefCell<T>/подобие Mutex<T>, это уже как раз один из примитивов interior mutability, и он лишь содержит значение и какие-то значения требуемые для синхронизации, он не аллоцирует (Разве что ОС может требовать для примитивов синхронизации аллокацию), и чтобы его клонировать нужно обернуть его в Arc<RwLock<_>> Ну и да, interior mutability необходимое зло, потому что как иначе Arc<Mutex<T>> работать должен, если mutability не позволяет иметь больше одной ссылки на изменяемое значение.
	Ответить | Правка | Наверх | Cообщить модератору

	438. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (438), 05-Апр-25, 11:25
	> Всё равно эта interior mutability выглядит как костыль. Она и есть костыль. rust на этапе компиляции доказывает выполнение инварианта shared^mutable. Этот инвариант, при всей его мощи, накладывает чувствительные ограничения на программиста. Растоманы нашли способы уворачиваться от проблем возникающих из-за них, но бывают случаи, когда увернуться не удастся, и хош или не хош но придётся иметь shared&mutable переменную. И здесь основная идея -- перенос отвественности за отсутствие data race с компилятора на программиста. RefCell например, при попытке взять мьютабл ссылку на содержимое, проверяет что нет активных мьютабл ссылок. Это те же проверки, что делает компилятор, но в рантайме. Атомики не проверяют, потому что они атомики, они гарантируют отсутствие дата рейсов другими способами, но в любом случае, ответственность за то, что атомики не порождают датарейсов лежит на разработчиках библиотечного кода атомиков, не на компиляторе. > Например тот же Rc/Arc/RwLock можно клонировать и потом мутировать, но при этом он будет таким же уникальным, за счёт блокировок, а не за счёт уникальности указателя. Rc/Arc/RwLock не Copy типы и для них надо явно делать clone только потому, что программист в целом хочет чтобы увеличение ref_count'а было бы явным. Это очень недешёвая операция, атомики вообще дорогое удовольствие, и поэтому было бы неплохо обходится без изменений ref_count'а настолько, насколько это возможно. Если бы изменения ref_count'а были бы бесплатными, если бы их можно было бы спрятать в Copy и после этого утверждать о 0-cost abstraction, не сталкиваясь с волной смеха критиков, то все эти типы были бы Copy: они по природе своей immutable shared указатели, раст нисколько не препятствует созданиям новых копий таких указателей. И я к тому, что слово "уникальный" по отношению к этим копиям совершенно неуместно, они копии и неуникальны. Вот когда ты создаёшь mutable указатель на значение, для которого Rc считает ссылки, вот тогда Rc будет проверять, что он уникальный, и хрена с два даст тебе mutable указатель, если ref_count > 1. Но если он даст, то вот про _этот_ указатель уже можно говорить, что он уникальный: проверка ref_count'а в рантайме это гарантирует.
	Ответить | Правка | К родителю #342 | Наверх | Cообщить модератору

	191. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 12:07
	>суть странности что стандартные атомики как я понял не требуют mut чтобы изменять значение. Вы неправильно понимаете назначение mut. Смысл mut в том, что имя переменной может указывать на другую переменную, а не в том, что переменная может меняется. let f = AtomicI8::new(1); let s = &f; s.store(2, Ordering::Relaxed); print!("{} {} ", f.load(Ordering::SeqCst), s.load(Ordering::SeqCst)); s.store(3, Ordering::Relaxed); println!("{} {}", f.load(Ordering::SeqCst), s.load(Ordering::SeqCst)); f и s указывают на одну и ту же переменную, по этому будет распечатано 2 2 3 3. let f = AtomicI8::new(1); let t = AtomicI8::new(2); {     let mut s = &f;     s.store(3, Ordering::Relaxed);     print!("{} ", s.load(Ordering::SeqCst));     s = &t;     print!("{} ", s.load(Ordering::SeqCst));     s.store(4, Ordering::Relaxed);     print!("{} ", s.load(Ordering::SeqCst)); } println!("{} {}", f.load(Ordering::SeqCst), t.load(Ordering::SeqCst)); В начале f и s указывают на одну и ту же переменную, однако потом s изменяется и начинает указывать на ту же переменную, что и t. Выведет 3 2 4 3 4
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

140. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
Сообщение от Аноним (140), 04-Апр-25, 09:34
Люди такие забавные: cпецификацию им сразу подавай, стандарт ISO им сразу подавай. Вспомните в каком году появился С++, а затем вспомните когда появился его первый стандарт ISO; и наконец посчитаейте сколько лет ушло на то чтобы родить первый стандарт ISO!
Ответить | Правка | Наверх | Cообщить модератору

	150. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Аноним (150), 04-Апр-25, 10:27
	давайте мы будем набивать каждый раз одни и те-же шишки :) но диды то по граблям ходили так как другого пути не было, а внучки под крики "диды устарели" бегут "на зло рекордам" по тем же граблям...
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 10:51
	> давайте мы будем набивать каждый раз одни и те-же шишки :) Так в этот раз намного лучше получилось! К моменту стандартизации с++ успели наовнячить кучку несовместимых реализаций. Плюс от сишки досталось ведро UB в наследство. А у раста одна эталонная реализация: сам Ferrocene это надстройка, а всякие gccrs пока еще нерабочие и им придется адаптироваться, если вдруг они понаписывали что-то несовместимое.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (189), 04-Апр-25, 12:20
	>  всякие gccrs пока еще нерабочие и им придется адаптироваться А вот х... С большой долей вероятности, если продолжится работа над внедрением rust в ядро - у gccrs будут шансы реализовывать ВЕРСИЮ rust для ядра. И она будет постоянно отдалятся.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 12:33
	>  у gccrs будут шансы реализовывать ВЕРСИЮ rust для ядра. Которая кроме ядра будет нужна чуть меньше чем нигде. А потом гнутики будут ныть что FF и прочий софт, использующий раст, не собирается gcc или собирается, но работает не так как ожидается. А с другой стороны - зачем? Сейчас все изменения для R4L возвращаются в апстрим. > И она будет постоянно отдалятся. Не потянут они свою версию.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 13:02
	>Плюс от сишки досталось ведро UB в наследство. Дядя ты болен и бредешь. UB плюсов - это баг самих плюсов. Божественную сишку тебе не замарать, это отдельный язык.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	265. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 14:48
	Разыменновывание nullptr - это баг крестов унаследованых от замаранной этим же багом сишки. Отсутствие гигиентических макросово - тоже сишка замарала кресты. Список можно продолжать
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Аноним (277), 04-Апр-25, 15:00
	Нее, чувак, ты не сможешь обелить дыряшку. UB плюсов - это тяжелое наследие сишки, которая была взята за основу для с++ Давай почитаем что пишет Bjarne Stroustrup в "A History of C++: 1979−1991" "The evolution of C++ is traced from C with Classes to the current ANSI and ISO standards work. ... The work and experience with C with Classes from 1979 to 1983 determined the shape of C++." ... This was what made C with Classes and later C++ a general−purpose language rather than a C variant with extensions to support specialized applications." ... C with Classes and later C++ follow this path by retaining the low−level and unsafe features of C." ... C with Classes was still seen as a dialect of C." и так далее stroustrup.com/hopl2.pdf Во всем виновата сишка :) Change My Mind
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	418. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (414), 05-Апр-25, 00:37
	> Change My Mind Зачем? Ему достаточно тебя перекричать. Здоровому человеку упорства не хватит сопротивляться, опровергать под каждой новостью. Добавлю: Why are some things left undefined in C++? Because machines differ and because C left many things undefined ... Note that many "things" that people refer to as "undefined" are in fact "implementation defined" https://www.stroustrup.com/bs_faq2.html#undefined
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (310), 04-Апр-25, 16:34
	>всякие gccrs пока еще нерабочие и им придется адаптироваться, если вдруг они понаписывали что-то несовместимое. Ну вы же понимаете, что есть такая опция -std=, где можно будет указать: вот это для удовлетворения Rust Foundation, а это для творчества вне Rust Foundation ;)
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	365. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (365), 04-Апр-25, 19:07
	> Ну вы же понимаете, что есть такая опция -std=, где можно будет указать Нет, не понимаю. -std= это из мира дыряшки, в rust существуют редакции, и все они официальные.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 10:52
	> Люди такие забавные: cпецификацию им сразу подавай, стандарт ISO им сразу подавай. Угу, не дай бог таки ее примут, так у сишников главный аргумент отвалится. > Вспомните в каком году появился С++, а затем вспомните когда появился его первый стандарт ISO Лучше уже с СИшкой сравнивать) Там еще круче 78 - 89, а не 85 - 98. Причем юникс на нее переписали без всяких стандартов. При стандартизации главное не начать ее слишком рано, и не настандартизировать какую-то чушь, а потом бороться с последствиями. Так же важно на начать слишком поздно, когда уже 100500 несовместимых трансляторов и реализаций, все пытаются пропихнуть свои решения как единственно верные. В итоге куча нелогичностей, UB и одинаковый код который на разных компиляторах дает разный результат. "Волшебник никогда не опаздывает, Фродо Бэггинс. Как и не приходит рано. Он приходит именно тогда, когда нужно." (с)
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

171. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
Сообщение от Медведь (ok), 04-Апр-25, 11:33
Допустим, корявый синтаксис rust -- на любителя, и дело привычки. Но rust по своей парадигме требует слишком много boilerplate кода, к тому же еще и очень "размазанного" по исходникам: структуры данных надо описать отдельно, имплементацию методов для них -- отдельно, имплементацию каждого типажа -- отдельно, причем наследовать реализацию и/или данные нельзя, явно выразить реализацию типажей через делегирование их к включенным через композицию полям данных -- нельзя, нужно явно определить каждый метод типажа и дернуть из него соответствующий метод поля... Чуть спасают ситуацию методы по умолчанию в типажах и генерики, но в итоге получается еще большая "каша" в коде, еще и приправленная enum'ами, которое совсем не то, что вы подумали, а суть некий аналог std::variant из C++ или record ... case ... of в Pascal. Ради чего все это нагорожено -- я теряюсь в догадках, но выглядит очень криво.
Ответить | Правка | Наверх | Cообщить модератору

	183. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 11:53
	Что значит "нагорожено"? Всё, что вы перечислили — возможности по абстрагированию, которые дают больше мощи программисту. И синтаксис (местами) сложный не потому, что кому-то захотелось всех запутать, а потому что даёт инструмент. Если вам не нужны или чужды возможности и средства Раста, вы просто игнорируете его. (и вообще, на мой взгляд Rust скорее простой для использования язык; никогда не понимал этого нытья)
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от Медведь (ok), 04-Апр-25, 11:58
	Ну да, ну да, объявим кривоту достоинством, зато не как у всех. В том и дело, что этих "возможностей по абстрагированию" куда меньше чем у языков с нормальной реализацией ООП. То есть rust реализует этакое "недоООП", но зато обозвав интерфейсы типажами, отрубив ряд возможностей и добавив необходимости писать больше ненужного кода. Замечательно!
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Facemaker (?), 04-Апр-25, 12:13
	> с нормальной реализацией ООП Этот слон давно не продаётся ☺
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 13:07
	> Этот слон давно не продаётся ☺ Потому что не модный!!! Устарел (С)
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 16:46
	>Потому что не модный!!! Устарел (С) Нет. Потому что ВНЕЗАПНО парадигма ООП оказалась ограниченно применима, как и всё остальное в нашем лучшем из миров. А её пытались пихать везде. Что касается наследования классов вместе с данными, то это из ряда изначальных ошибок дизайна, вместе с нуль-терминированными строками и NULL-указателями.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (140), 04-Апр-25, 13:22
	>>> с нормальной реализацией ООП <<< Практика показала, что у ООП, в том виде в котором он есть в других языках, куча проблем которые приходится героически решать всякими костылями! Я это к тому, что не нужно думать что ООП это какая-то панацея (также как и сам Rust не является лекарством от всех бед!), - вы вообще можете решить задачу в функциональном стиле, если хотите! Многих разработчиков десятилетиями уверяли что ООП божественен и прекрасен, - как результат у многих разработчиков просто случился ООП головного мозга и они в принципе ничего не могут без ООП и городят его там где он вообще ни к чему!
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	231. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 13:39
	Да ладно, профита значительно больше. ООП - это просто удобно, ускоряет разработку. И то что в Расте нормального ООП нет - жирный минус для Раста. Но согласен в том, что избыточно городить объекты нет смысла там, где хватает и процедурного стиля. То же самое касается и шаблонов - желательно их использовать только когда это действительно необходимо, а не всегда и везде.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 18:44
	> И то что в Расте нормального ООП нет - жирный минус для Раста. То, что в Расте нормального ООП нет — жирный миф. Есть всё, что нужно для ООПнутого мозга, кроме множественного наследования и наследования данных, то есть самого вредного.
	Ответить | Правка | Наверх | Cообщить модератору

	363. Скрыто модератором	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 19:03
	>То, что в Расте нормального ООП нет — жирный миф В расте нет никакого ооп, ни нормального, ни ненормального. >кроме множественного наследования и наследования данных Путь раста - это копипаста
	Ответить | Правка | Наверх | Cообщить модератору

	419. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 05-Апр-25, 00:54
	> кроме ... наследования данных, то есть самого вредного. то есть, самого базового и важного. понятно откуда берутся истерики про ООПнутость, потому что нормально её там просто не реализовали.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	234. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Медведь (ok), 04-Апр-25, 13:46
	> Практика показала, что у ООП, в том виде в котором он есть в других языках, куча проблем которые приходится героически решать всякими костылями! Примеры костылей с ООП, от которых избавляет rust, в студию пожалуйста, или незачет. Отнюдь не считаю ООП серебряной пулей, но в ряде предметных областей наблюдаются вполне естественные иерархии, которые отлично в парадигму ООП ложатся.
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	238. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (140), 04-Апр-25, 13:53
	П>>> римеры костылей с ООП, от которых избавляет rust, в студию пожалуйста, или незачет. <<< множественное наследование
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Медведь (ok), 04-Апр-25, 14:00
	> множественное наследование Очень полезная вещь при комбинировании ортогональных сущностей. Это всё?
	Ответить | Правка | Наверх | Cообщить модератору

	427. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 03:36
	>Очень полезная вещь при комбинировании ортогональных сущностей. На самом деле довольно вредная, потому что существенно затрудняет понимание кода и чревато ошибками. Многие рекомендуют обходить его стороной и заменять композицией. >Это всё? Нет это не всё. Многоэтажное наследование тоже зло и по той же причине.
	Ответить | Правка | Наверх | Cообщить модератору

	458. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 05-Апр-25, 21:56
	> Очень полезная вещь при комбинировании ортогональных сущностей. Совершенно избыточная. Ортогональные сущности легко и непринуждённо комбинируется таким образом: struct Composite {     a: First,     b: Second, } Чтобы создать второй способ это сделать затевать бодягу с множественным наследованием? В чём прикол?
	Ответить | Правка | К родителю #243 | Наверх | Cообщить модератору

	402. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Ан Оним (?), 04-Апр-25, 21:40
	Сделайте запрос "недостатки ооп" и удивитесь. Например https://tproger.ru/translations/oop-the-trillion-dollar-disa... "Часто упоминается, что инкапсуляция является одним из величайших преимуществ ООП. Предполагается защитить внутреннее состояние объекта от внешнего доступа. Но есть небольшая проблема. Это не работает. Инкапсуляция — это троянский конь ООП. Он продвигает идею общего изменяемого состояния, делая его, казалось бы, безопасным. Инкапсуляция позволяет небезопасному коду проникать в кодовую базу (и даже поощряет это), заставляя её гнить изнутри."
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	456. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 05-Апр-25, 19:36
	> в ряде предметных областей наблюдаются вполне естественные иерархии Наблюдения "естественных иерархий" я считаю симптомом того, что мозги наблюдающего были отформатированы объектной ориентированностью. Нет никаких "естественных" иерархий, то что кажется естественным не более чем первый выхлоп с генеративной нейросети, которая ищет способ решить проблему. И содержимое этого первого выхлопа говорит лишь о том, на поиск какого рода решений эта нейросетка натаскана, и вовсе не о том, какого рода решения лучше для задачи.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	403. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Ан Оним (?), 04-Апр-25, 21:43
	>rust реализует этакое "недоООП", В Rust'е, можно сказать, вообще нет ООП, потому что мир движется в сторону более простых и в то же время более надёжных технологий.
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	210. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Анончоус (?), 04-Апр-25, 12:37
	> явно выразить реализацию типажей через делегирование их к включенным через композицию полям данных -- нельзя, нужно явно определить каждый метод типажа и дернуть из него соответствующий метод поля... Для одного поля и можно https://rust-unofficial.github.io/patterns/anti_patterns/der... но это антипаттерн. Стоит задуматься на структурой кода. Если нужно оборачивающую структуру передавать в методы, принимающие impl Trait, то да, нужно явно реализовать, но мне кажется существует крейт с макросом, который этот boilerplate генерирует. >  приправленная enum'ами, которое совсем не то, что вы подумали В чем проблемы? В ключевом слове? По-факту очень крутая фича, реализованная в языке, а не в либе.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	254. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Медведь (ok), 04-Апр-25, 14:18
	И зачем было менять смысл термина enumeration, уже устоявшегося в ряде языков? Чтоб не как у всех? Ну и welcome to записи с вариантами в Pascal, union в C/C++, несть им числа, ничего нового тут в расте не изобретено.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 14:35
	Какой термин у enumeration? В Swift, Scala enum имеет такой же смысл как и в расте. Или они тоже неустоявшиеся? Можешь в свою методичку забрать https://doc.rust-lang.org/reference/influences.html чтобы показывать, что раст всё своровал.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от freecoder (ok), 04-Апр-25, 14:03
	Хорошая фича языка держать отдельно определение полей структуры и её методов. Отдельные блоки могут имплементировать методы для разных ограничений обобщённых типов, могут быть скрыты фичами условной компиляции, проще могут генерироваться макросами и т.д. Да и воспринимать их проще, когда поля и методы отделены.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	249. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Медведь (ok), 04-Апр-25, 14:13
	Уверен, будь так реализовано в C# или C++, растофилы вопили бы об этом как о страшном недостатке ;) Нет в этом ничего удобного.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 14:41
	Фантазер. А мне вот удобно. Будут еще аргументы? В расте структуры представлены просто явными данными и ничем больше. Даже при использовании динамической диспетчеризацией ссылка на vtable хранится в fat pointer-е, а не в самом экземпляре структуры.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Facemaker (?), 04-Апр-25, 17:35
	>Хорошая фича языка держать отдельно определение полей структуры и её методов. Конечно. Даже в C++ считается бонтоном выносить реализации inline-методов за пределы объявления класса.
	Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

	266. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 14:51
	> еще и приправленная enum'ами, которое совсем не то, что вы подумали, а суть некий аналог > std::variant из C++ или record ... case ... of в Pascal. А что с ними не так? Предположу что убогая реализация из С/C++ где "все есть int", и позволяющая сравнивать абрикосы с крокодилами, сейчас никому не нужна. Другое дело enum из swiftʼа - там есть и ассоциированные значения, и проверка семантики. Людям нужен паттерн матчинг, инварианты и прочие блага цивилизации.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	269. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (269), 04-Апр-25, 14:54
	Ты просто отстал от развития индустрии. Наследование мертво. Это не баг, это фича.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	420. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от fuggy (ok), 05-Апр-25, 01:25
	ООП одна из множества парадигм. Может от недостатков ли ООП в них появились extension methods и default methods в интерфейсах? Которые по сути те же трейты. Данные отдельно, методы отдельно это удобно. Потому что для структуры можно реализовать много трейтов. А что в ООП, в нём можно реализовать несколько интерфейсов, но тогда копипастить каждую функцию во все классы или отнаследоваться от единственного класса с его функциями. От наследования сейчас все отказываются и оно спокойно заменяется на композицию. И в Rust можно сделать ООП подобный подход как в C++ с vtable. В Rust есть dyn Trait который позволяет сделать динамическую диспетчеризацию и через неё получить полиморфизм как в ООП. А простые generics в Rust и без этого есть. Тип-сумма enum в Rust это вообще понятие из математики. И чем же заменяется оно в ООП языках, ведь там нет аналога std::variant. Заменяется разве что через if instanceof и маркерными интерфейсами. Которое работает значительно дольше чем enum.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

187. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от Аноним (111), 04-Апр-25, 12:00
Какая есть бесплатная система программирования для Rust (желательно кроссплатформенная) с IDE, отладчиком, дизайнером формочек, доступом к БД (желательно), с примерами разными типа чтения-записи файлов в популярных форматах, графиков разных, анимации, системными штуками? Покажут - тогда и поговорим.
Ответить | Правка | Наверх | Cообщить модератору

	190. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 04-Апр-25, 12:06
	> Покажут - тогда и поговорим О чём с тобой разговаривать? О формочках и анимации?
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (111), 04-Апр-25, 12:35
	> О чём с тобой разговаривать Поймал! В этом и дело. О Rust только поговорить. Этим заканчивается.
	Ответить | Правка | Наверх | Cообщить модератору

	428. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 03:42
	>О Rust только поговорить. Этим заканчивается. Разве что для балаболов, которые к программированию не имеют никакого отношения.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+2 +/–
	Сообщение от freecoder (ok), 04-Апр-25, 14:05
	VSCode хватает для всех задач. Которые не покрывают rustup и cargo с плагинами.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

202. Скрыто модератором	+1 +/–
Сообщение от anonymmmeer (?), 04-Апр-25, 12:24
С увольнением верхушки АНБ, которые рекомендовали перестать использовать C и C++, суета вокруг Rust уменьшится, всё будет норм. главная проблема Rust это попытка навязывать его как MVP, как стартап... сначала минимально юзабельное говно + жёсткая реклама + основной посыл, что всё вокруг ещё более неюзабельное говно. Нет, чтобы делать нормально и юзабельно и потихоньку завоёвывать сердца инженеров. Уже сейчас видно, что не взлетит. p.s. логика заимствований недостаточно изучена вообще, это вам не старые добрые множества
Ответить | Правка | Наверх | Cообщить модератору

	208. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 12:34
	> С увольнением верхушки АНБ, которые рекомендовали перестать использовать C и C++, суета вокруг Rust уменьшится, всё будет норм. Ого, у нас тут инсайдер прямо из АНБ. Ничоси! > главная проблема Rust это попытка навязывать его как MVP, как стартап... сначала минимально юзабельное говно + жёсткая реклама + основной посыл, что всё вокруг ещё более неюзабельное говно. Феерический бред. Чуваки делали ЯП для себя. И писали на нем тоже для себя. Уже позже начали подтягиваться корпы, которых заколебало ловить уязвимости от безмозглых недопрограммеров. > Нет, чтобы делать нормально и юзабельно и потихоньку завоёвывать сердца инженеров. Как дыряшки и дыряшку++ ? > Уже сейчас видно, что не взлетит. Ух какой забористый копиум. Про "да не добавят раст в ядро" тоже говорили. В общем "вы находитесь здесь" (с) > p.s. логика заимствований недостаточно изучена вообще, это вам не старые добрые множества Ага, а еще старые добрые enum'ы в виде интов, старые добрые cast void*, ну и старые добрые UBшки, костыляя которые можно выиграть пару тактов, а потом отстрелить ноги по самую *опу. И вообще надо работать по стандартам прошлого тысячелетия, а не играться в прогресс!
	Ответить | Правка | Наверх | Cообщить модератору

214. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+4 +/–
Сообщение от Аноним (214), 04-Апр-25, 12:52
Не разбираюсь в качестве языка, однако, что меня отталкивает в rust - это то, с какой маниакальной настойчивостью, буквально насильно, пытаются его "популяризировать". Нет такого, как с Go(из новых языков), когда разработчики решают: "О, прикольный язык, напишу пожалуй свою утилиту/программу на нём." Разработчики на Rust почему-то хотят не что-то новое создавать на этом языке, а именно переписать старое. Почему-то мне кажется, что их психологический профиль совпадет с таковым у сторонников "декоммунизации" и подобного.
Ответить | Правка | Наверх | Cообщить модератору

	220. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Прохожий (??), 04-Апр-25, 13:12
	> пытаются его "популяризировать". Думаю, вы не правы. Если бы хотели "популяризировать", как вы выразились, предложили бы качественный инструментарий, публикации "историй успеха", доброжелательное отношение. А та "популяризация", что мы видим, ведет к негативу и отвлекает от дела. По стилю очень напоминает давние заговоры против Linux, выражавшиеся в патентном преследовании, попытках продавать лицензии, дезинформации, сеянии сомнения среди разработчиков.
	Ответить | Правка | Наверх | Cообщить модератору

	429. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Прохожий (??), 05-Апр-25, 03:49
	>предложили бы качественный инструментарий, публикации "историй успеха", доброжелательное отношение Слона-то я и не заметил (c). Всё это есть. Просто некоторые (многие), которые "вложились" в какой-то другой язык программирования, уже морально устаревший, теперь не хотят переучиваться (это сложно, да и не всем под силу). Другие просто не понимают зачем им нужен Rust, когда они всю жизнь на Питоне программировали. И так далее в том же духе.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от xsignal (ok), 04-Апр-25, 13:37
	Да, сейчас в интернете развёрнута масштабная кампания по дискредитации языка Си, философии UNIX и открытых систем, с параллельной раскруткой раста как "волшебной таблетки" от всех болезней, причём раскрутка ведётся разветвлённой сетью раст-миссионеров, представители которой обосновались на всех IT сайтах и форумах и под каждым тематическим постом поют дифирамбы расту и поливают грязью Си.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	235. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 13:47
	> Да, сейчас в интернете развёрнута масштабная кампания по дискредитации языка Си, Неужели растовики изобрели машину времени и подкладываю овнокод прямо в штаны дидов? Создавая выходы за буфер, use-after-free и прочие типичные ошибки памяти в кодах 20-30 летней давности? Какое чудовищное коварство! Я знал, что они злодеи!! Или они просто тычут бракоделов мордочкой, вот прям в результаты их жизнедеятельности?
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от xsignal (ok), 04-Апр-25, 13:53
	> дидов И да, также действует кампания по нивелированию великих достижений патриархов IT и гениев программирования прошлых лет, пренебрежительное называние их "дидами" и создание ложного представления, будто они ничего такого не создали, а только ошибки в программах делали.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 13:59
	> И да, также действует кампания по нивелированию великих достижений патриархов IT и гениев программирования прошлых лет О, они делали великие достижения! Например сэкономтили целый байт и придумали Null-terminated string, которым отстреляли столько ног, что было названо "the most expensive one-byte mistake") > пренебрежительное называние их "дидами" Там половина уже померла, что их называть "молодыми и красивыми")? > создание ложного представления, будто они ничего такого не создали, а только ошибки в программах делали. Каждый может совершить ошибку. Но некоторые их не признают, да еще и упираются рогами "мол и так сойдет".
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от xsignal (ok), 04-Апр-25, 14:07
	> О, они делали великие достижения! Представь себе, да. Все фундаментальные технологии современного IT, всё, что сейчас тихо и незаметно "просто работает", всё, на чём стоит и за счёт чего движется весь Интернет - от этих самых "дидов"! > ридумали Null-terminated string, которым отстреляли столько ног "Дай дураку х** стеклянный, он и х** разобьёт и руки порежет" > Там половина уже померла Тем более стоит проявить уважение.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 14:13
	> Представь себе, да. Все фундаментальные технологии современного IT, всё, что сейчас тихо и незаметно "просто работает", всё, на чём стоит и за счёт чего движется весь Интернет - от этих самых "дидов"! А если "просто не работает"? Или "баги вычищаем годами и конца-края не видно"?. Ну т.е можно принять позу ополизов и рассказывать "как оно было прекрасно в средние века! а то что за гобеленом было нагажено, то это дух времени". >> ридумали Null-terminated string, которым отстреляли столько ног > "Дай дураку х** стеклянный, он и х** разобьёт и руки порежет" Ага, только дыряшечные ошибки совершают все. Даже такие акса-кал-ы типа Теодора Тцо. Нет в мире Настоящих Сишников! Вот они точно бы не делали таких глупых багов! >> Там половина уже померла > Тем более стоит проявить уважение. О мертвых либо хорошо, либо ничего кроме правды (с) Надо учиться на ошибках прошлых поколений. Не зря они их делали.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 15:05
	>Представь себе, да. Все фундаментальные технологии современного IT, всё, что сейчас тихо и незаметно "просто работает" Основная проблема в том, что это "просто работает" нужно давным давно выкинуть и написать нормально, но сумма будет настолько астрономической, что эта идея ужасает даже тех, кто о ней говорит >"Дай дураку х** стеклянный, он и х** разобьёт и руки порежет" Нормальных аргументов у вас изначально не было или они резко закончились? Хороший инструмент активно противодействует совершению ошибок, а не поощрает их.
	Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

	289. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от xsignal (ok), 04-Апр-25, 15:23
	> выкинуть и написать нормально Ну выкинь TCP/IP и напиши принципиально новый "нормальный" протокол > Хороший инструмент активно противодействует совершению ошибок, а не поощрает их Значит скрипка - плохой инструмент: крайне неудобный, струны режут пальцы, долго учиться, высокий порог вхождения, одно неверное движение смычком - и фальшивая нота. Другое дело - синтезатор! Все ноты на своих клавишах, не ошибёшься, удобно, безопасно для рук!
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 16:49
	>Ну выкинь TCP/IP и напиши принципиально новый "нормальный" протокол Как там с IPv6 связностью дела обстоят? В некоторых местах связность будет не дальше локалхоста, так как провайдерский роутер в IPv6 не умеет даже в локалке, а если воткнуть провод напрямую, то тоже будет только IPv4. >Значит скрипка - плохой инструмент: крайне неудобный, струны режут пальцы, долго учиться, высокий порог вхождения Да, всё так >Другое дело - синтезатор! Все ноты на своих клавишах, не ошибёшься, удобно, безопасно для рук! Давайте, попробуйте на скрипке сыграть то же техно. Можете хоть целый симфонический оркестр притащить, а я послушаю, что у вас получится.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Анончоус (?), 04-Апр-25, 14:13
	Безусловно существует много технологий и ПО, порожденные "дидами", но все они имели, имеют и будут иметь баги и уязвимости. Раст же предлагает сократить количество багов, уязвимостей определенного класса. В чем минус этого "буллет поинта" при продвижении языка?
	Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

	286. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от ptr (ok), 04-Апр-25, 15:12
	> В чем минус этого "буллет поинта" при продвижении языка? Именно в том, как он происходит. Для подавляющего большинства адекватных людей это выглядит, как упорная попытка всучить нольпроцентный кредит, в договоре которого мелкими буквами фиксируется чуть ли не продажа души дьяволу. Стиль точно такой же. Очень редко попадается адекватное продвижения Rust, где честно и наглядно показываются все pros и cons. В 99% случаев стиль продвижения неотличим от рекламы вечных презервативов или самоходных унитазов. Не удивительно, что такой стиль внушает у многих отвращение не только к пропагандисту, но и рекламируемому объекту, который в данном случае только страдает.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Анончоус (?), 04-Апр-25, 15:31
	С этим согласен. Когда впервые о расте услышал и о бесконечных рекламах, какой он крутой, убийца плюсов, испытывал некое отвращение. Потом как-то забил на эти желтушные заголовки и начал писать на расте for fun.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 15:47
	> Именно в том, как он происходит. Для подавляющего большинства адекватных людей Какое интересно обобщение. А эти "большинство адекватных" как определили? Может опрос проводили? Потому что на всяких стековерфлоу и гитхабах тоже есть опросы, но результаты слегка другие. Кому ж верить? > это выглядит, как упорная попытка всучить нольпроцентный кредит, в договоре которого мелкими буквами фиксируется чуть ли не продажа души дьяволу. Стиль точно такой же. Гипербола это хорошо, сразу показывает уровень дискуссии. > Очень редко попадается адекватное продвижения Rust, где честно и наглядно показываются все pros и cons. Зачастую cons сводятся или к узкоспециализированным нишам - типа микроконтроллеров или 100500 контенеров. Или к вкусовщине "мне так синтаксис не нравится, аж кушать не могу!" > В 99% случаев стиль продвижения неотличим от рекламы вечных презервативов или самоходных унитазов. Рекламу где показывают по телевизору? на ютубе? по радио? > Не удивительно, что такой стиль внушает у многих отвращение не только к пропагандисту, но и рекламируемому объекту, который в данном случае только страдает. Не думал что айтишники настолько ранимые существа. Но когда дело доходит до хейта, то не учитываются ни опыт, ни авторитет (не люблю такую аргументацию, но объективно есть куча людей которые разбираются лучше меня) - типа как было с Грегом. Агрументация ad veritatem тоже не прокатывает - ты говоришь "вот у гугл отчитался что на 1.5 миллиона строк ни одной ошибки по памяти" - получаешь ответ "гугл все врет! это реклама!!!" вещественно без каких либо доказательств.
	Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

	304. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 16:20
	> А эти "большинство адекватных" как определили? Очень просто. Если реклама не соответствует ст.5 Закону "О рекламе", то она не расчитана на адекватных людей. И даже только в этой ветке, если посмотреть на попытки рекламы Rust, подавляющее большинство таких сообщений грубо нарушают требования указанной статьи. Изучите: https://secrets.tbank.ru/trendy/kak-ispolzovat-sravneniya-v-.../
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (311), 04-Апр-25, 16:36
	>> А эти "большинство адекватных" как определили? > Очень просто. Если реклама не соответствует ст.5 Закону "О рекламе", то она не расчитана на адекватных людей. Погоди, у закона о рекламе есть четкие определения рекламы. Тут надо сначала доказать, что это реклама. Если в теме про "в GRUB2 уязвимость - жмакаешь backspace 28 раз - получаешь рут", написать что-то вроде "никогда такого не было и вот опять" то это реклама? Если да, то чего? > И даже только в этой ветке, если посмотреть на попытки рекламы Rust, подавляющее большинство таких сообщений грубо нарушают требования указанной статьи. > Изучите: https://secrets.tbank.ru/trendy/kak-ispolzovat-sravneniya-v-.../ А можно, пожалуйста номер сообщения или ссылку. Интересно посмотреть на "рекламу". Более того, есть такое понятие как солиальная реклама - для нее совершенно другие требования. Например - "невнимательность за рулем может привести к страшным последствиям", "Давайте запретим продавать алкоголь после 10 вечера", "водитель превышающий скоростной режим - потенциальный преступник!". Примерно то же самое можно написать про non-safe языки.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 17:46
	> Тут надо сначала доказать, что это реклама. Достаточно прочитать определение в законе. "реклама - информация, распространенная любым способом, в любой форме и с использованием любых средств, адресованная неопределенному кругу лиц и направленная на привлечение внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижение на рынке;" > Если в теме про "в GRUB2 уязвимость - жмакаешь backspace 28 раз > - получаешь рут", написать что-то вроде "никогда такого не было и > вот опять" то это реклама? Прочитайте определение. > А можно, пожалуйста номер сообщения или ссылку. Интересно посмотреть на "рекламу". > Более того, есть такое понятие как солиальная реклама "Социальная реклама не преследует коммерческих целей, не формирует интереса к товару для его продвижения на рынке, под социальной рекламой понимается исключительно информация, направленная на достижение благотворительных и иных общественно полезных целей, а также обеспечение интересов государства." > Примерно то же самое можно написать про non-safe языки. А это при чем? Или в Rust unsafe отменили? Я только за последний год несколько десятков раз правил ошибки в коде на Rust, связанные с некорректной работой с памятью. Причем ни разу эти ошибки не содержались непосредственно в unsafe блоке, а вызывались некорректными данными, формируемыми вне unsafe блоков.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 18:34
	> и его продвижение на рынке; Ну вот это уже не выполняется. Раст не продается и не покупается. Компилятор вообще бесплатный. > Прочитайте определение. А по существу есть что сказать? Определение я прочитал. И по нему никакие заявления вроде "прекратите выходить за границы массива!" не является рекламой. Хотя в теории на социалку можно и попробовать натянуть "направленная на [...] общественно полезных целей, а также обеспечение интересов государства" Можно что первое - софт станет надежнее для юзера, что второе - софт станет надежнее пред лицом недругов-буржуинов. > Причем ни разу эти ошибки не содержались непосредственно в unsafe блоке, а вызывались > некорректными данными, формируемыми вне unsafe блоков. А чем заключались эти ошибки? Писалось за пределы буфера и выполняло чужок код? Или программа просто падала с паникой?
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 19:07
	> Ну вот это уже не выполняется. Раст не продается и не покупается. Компилятор вообще бесплатный. "объект рекламирования - результаты интеллектуальной деятельности [...] на привлечение внимания к которым направлена реклама" О платности или бесплатности не вижу ни слова. Вы никогда не встречали, например, рекламы бесплатных приложений для смартфонов?
	Ответить | Правка | Наверх | Cообщить модератору

	379. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 19:43
	>О платности или бесплатности не вижу ни слова. Мне тут стало очень интересно, являются ли красивые девушки на пляже рекламой презервативов/колясок что там по списку или нет? Зачем они перед походом на пляж красятся, как не чтобы стимулировать спрос на такие вещи? Так почему они ходят не получив свой номер для рекламы?
	Ответить | Правка | Наверх | Cообщить модератору

	392. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 20:37
	> Мне тут стало очень интересно, являются ли красивые девушки на пляже рекламой презервативов/колясок что там по списку или нет? Если указывается объект рекламы (конкретная марка презерватива, модель коляски и т.п.) - то явно реклама. > Так почему они ходят не получив свой номер для рекламы? Не понял о каком номере речь? Может указать конкретную статью и пункт Закона "О рекламе", на который Вы ссылаетесь? Можете смело напечатать на майке "Устанавливайте бесплатные Яндекс-карты, не пожалеете!" и ходить в ней где угодно. Никаких претензий от правоохранительных органов не будет. Гарантирую. Сам не раз ходил в подобных майках, полученных на выставках или конференциях. Даже с рекламой FIDONet.
	Ответить | Правка | К родителю #379 | Наверх | Cообщить модератору

	404. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 21:56
	> А чем заключались эти ошибки? Писалось за пределы буфера В том числе. "Сторожевая собака" отрабатывала. Хуже, если вдруг в регистры не то залетало. Тогда, например, DMA могло проехаться по вообще абстрактным данным и результат мог проявиться совсем в другом месте и в другое время. > и выполняло чужок код? Бывало, что портился стек, после чего управление попадало неведомо куда. Но на МК "чужой код" - понятие странное. Например, мне пришлось делать PR в esp-rs/esp-idf-hal, чтобы от этого избавиться. Но если там, благодаря Frederick Vollbrecht, мои PR мержились очень оперативно, то про esp-rs/embedded-svc такого не скажешь. > Или программа просто падала с паникой? Какая может быть паника при испорченном стеке? Да и толку от паники на МК?
	Ответить | Правка | К родителю #352 | Наверх | Cообщить модератору

	314. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 16:40
	Для начала пусть ненавистники Раста пометят каждое своё сообщение рекламой, особенно ложь и провокацию, тогда поговорим
	Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

	322. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 16:50
	Вы призываете уподобляться худшему из оппонентов? Это такой принцип продвижения Rust? Ну-ну )))
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (311), 04-Апр-25, 16:56
	> Для начала пусть ненавистники Раста пометят каждое своё сообщение рекламой, особенно ложь и провокацию, тогда поговорим Ненене, давай пусть сначала определятся "что такое реклама" в контексте ЯП. Потому что под "информация, распространенная любым способом, в любой форме и с использованием любых средств, адресованная неопределенному кругу лиц и направленная на привлечение внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижение на рынке" открытый и бесплатный ЯП подходит слабо.
	Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

	348. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 18:04
	> Ненене, давай пусть сначала определятся "что такое реклама" в контексте ЯП. > Потому что под "информация, распространенная любым способом, в любой форме и с > использованием любых средств, адресованная неопределенному кругу лиц и направленная на > привлечение внимания к объекту рекламирования, формирование или поддержание интереса > к нему и его продвижение на рынке" открытый и бесплатный ЯП > подходит слабо. "объект рекламирования - результаты интеллектуальной деятельности [...] на привлечение внимания к которым направлена реклама" О платности или бесплатности не вижу ни слова. Более того, с рекламой бесплатных программных продуктов, особенно для смартфонов, я сталкиваюсь регулярно.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 18:16
	> "объект рекламирования - результаты интеллектуальной деятельности [...] на привлечение > внимания к которым направлена реклама" Ок, принимается. Но скорее подпадает под "социальную рекламу", тк ʼнаправленная на достижение благотворительных и иных общественно полезных целей, а также обеспечение интересов государстваʼ А можно еще раз попросить, все-такие скинуть номер рекламного сообщения в этой теме. (или хоть кусок цитаты) Вдруг в нем действительно публикуют инфрмацию вводящую в заблуждение
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 19:04
	> Но скорее подпадает под "социальную рекламу", тк Не получается, так как социальная не формирует интереса к товару для его продвижения на рынке. Попробуйте доказать ФАС или в суде, что реклама бесплатных Яндекс-карт - это социальная реклама. Только пожалуйста, опубликуйте результаты здесь. Посмеёмся вместе )))
	Ответить | Правка | Наверх | Cообщить модератору

	380. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 19:46
	>> Но скорее подпадает под "социальную рекламу", тк > Не получается, так как социальная не формирует интереса к товару для его  продвижения на рынке. А рынок то где?) > Попробуйте доказать ФАС или в суде, что реклама бесплатных Яндекс-карт - это социальная реклама. Не-не-не, Девид Блейн, Я-карты бесплатные только для пользователей. А для остальных есть платное продвижение, всякие планы, анимрованные карточки и сторисы и тд. Можно открыть Я.Бизнес и убедиться самому. А теперь попробуем натянуть сову на глобус. У нас есть раст фоундейшн, которая озаботилась развитием языка. Язык бесплатный? Да. Может стандарт за деньги как для СИ? Нет, стандарта пока даже нету. *сова трещит но еще держится* Может документация или обучение платное? Тоже нет! *сове уже невмоготу* А, наверняка у них там сертификация, всякие курсы и вот тут уже обдерут как липку. Но нет! Удивительно. Т.е организация никак не зарабатывает, а только тратит деньги своих мемберов. Что логично, это же independent non-profit organization dedicated to stewarding the Rust programming language. non-profit в отличии от яндекса, который - публичная компания, есть акции. ps по вашей логике любой упоминание ядра Линукса и дистрибутив, успешных продуктов типа блендера, криты, гимпа (ну ладно, относительно успешного) - это реклама. А весь opennet - это рекламная площадка! ps2 насколько я помню, упоминание товаров или услуг (например RHEL) - является рекламой, не придут ли к владельцу сайта за такое агрессивное продвижение американских платных ОС? Да еще и без занесения в Единый реестр интернет-рекламы!
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

	399. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 21:07
	> А рынок то где?) "лица, на привлечение внимания которых к объекту рекламирования направлена реклама" > Я-карты бесплатные только для пользователей. А я писал про пользователей. Но если не нравятся Яндекс-карты, то в магазине приложений можете найти тысячи других бесплатных приложений. > по вашей логике любой упоминание ядра Линукса и дистрибутив, успешных продуктов типа блендера, криты, гимпа (ну ладно, относительно успешного) - это реклама. "если информация, размещенная в статье стороннего СМИ, блога (в том числе с использованием гиперссылки), формирует интерес к какому-либо товару (работе, услуге) с целью привлечения внимания к объекту рекламирования, указанная информация может подпадать под признаки рекламы, распространение которой должно осуществляться в соответствии с требованиями статьи 18.1 Федерального закона "О рекламе"." <Письмо> ФАС России от 29.05.2023 N 08/41716/23 "Об информации в сети "Интернет" При этом в соответствии с Законом "О рекламе" справочно-информационные и аналитические материалы рекламой не являются. Иными словами, до тех пор, пока Вы лишь анализируете программный продукт и сообщаете о нем какую-то информацию - это не является рекламой. А вот явная попытка сформировать интерес к этому программному продукту - уже реклама. То есть, пока Вы расписываете преимущества и недостатки любимого программного продукта - это аналитика. Но если Вы явно призываете этим продуктом воспользоваться неопределенный круг лиц, уж извините - реклама.
	Ответить | Правка | К родителю #380 | Наверх | Cообщить модератору

	409. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 22:51
	> "лица, на привлечение внимания которых к объекту рекламирования направлена реклама" Разумеется это не рынок, потребители рекламы. Ст. 3 38-ФЗ: > 8) потребители рекламы - лица, на привлечение внимания которых к объекту рекламирования > направлена реклама; А вопрос был про: "адресованная неопределенному кругу лиц и направленная на привлечение внимания к объекту рекламирования, формирование или поддержание интереса к нему и его продвижение на *рынке*" Вот на каком рынке идет продвижение раста? Но можем вернуться к определениям из того же ФЗ. Само определение рекламы предполагает наличие объекта рекламирования, которые определяется как "товар, средства индивидуализации юридического лица и (или) товара, изготовитель или продавец товара, результаты интеллектуальной деятельности либо мероприятие" Подпадает ли раст под что-то из этого? Прекрасно, когда автор статьи *призывает* перейти с винды на линукс, или с фотошопа на гимп тот самый неопределенный круг лиц, то это тогда реклама. Даже призывы перейти с Thunderbird на Betterbird или с RHEL на Альму легко подпадают под ваше же определение. Во втором случае даже все хуже, т.к. там конкретная аудитория "пользователи RHEL". > Иными словами, до тех пор, пока Вы лишь анализируете программный продукт и > сообщаете о нем какую-то информацию - это не является рекламой. Так мы и анализируем. Указываем на достоинства раста и недостатки. Сообщаем об новшествах. Ну и сравниваем его с аналогами. Хотя вполне можем просто вместо всего этого указывать на недостатки аналогов, даже не упоминая раст. Все и так все поймут, евпочя. Меня даже забавляют ваши упорные попытки интерпретировать новости и обсуждение раста как рекламу))
	Ответить | Правка | К родителю #399 | Наверх | Cообщить модератору

	416. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 05-Апр-25, 00:06
	> Вот на каком рынке идет продвижение раста? Если хотите более точно, то на рынке языков программирования. https://itproger.com/news/obzor-rinka-top-8-yazikov-programm... > как "товар, средства индивидуализации юридического лица и (или) товара, изготовитель или > продавец товара, результаты интеллектуальной деятельности либо мероприятие" > Подпадает ли раст под что-то из этого? Rust является результатом интеллектуальной деятельности. Вы с этим не согласны? > Прекрасно, когда автор статьи *призывает* перейти с винды на линукс Не реклама, если не указывается конкретный дистрибутив или его производитель. > фотошопа на гимп тот самый неопределенный круг лиц А это уже реклама, так как конкретизирован объект рекламирования. > Так мы и анализируем. Указываем на достоинства раста и недостатки. Сообщаем об > новшествах. До тех пор, пока это так - это не реклама. > Ну и сравниваем его с аналогами. А вот тут начинается тонкий лёд. Почитайте https://secrets.tbank.ru/trendy/kak-ispolzovat-sravneniya-v-.../ Например, если обсуждая Rust говорить о CVE в каких-то продуктах на C, то с точки зрения Закона "О рекламе" совершенно некорректно не указать так же, что только в rust-std за последние пять лет было полтора десятка CVE. Даже само утверждение "Rust - безопасный язык" - уже вводит потребителя в заблуждение, так как его безопасность ограничена только управлением памятью и потоками вне unsafe блоков, да и то не всегда. Посмотрите на инфраструктуру esp-rs https://github.com/esp-rs Там этих unsafe блоков больше сотни в сумме наберется! Вы уверены, что это безопасно? Я вот уверен в обратном, так коммитил туда исправления ошибок, в том числе и при работе с памятью. И наверняка таких ошибок там еще не мало осталось. Причем, подавляющее большинство исправленных мной ошибок было не в самих unsafe блоках. Например, при освобождении AdcContDriver в esp-idf-hal просто забыли остановить DMA. В результате тот продолжал хреначить данные с ADC в область памяти освобожденного буфера по кругу. Нужно объяснять, к каким последствиям это приводило? > Меня даже забавляют ваши упорные попытки интерпретировать новости и обсуждение раста как > рекламу)) Где Вы это увидели? Я наоборот указал, что справочно-информационные и аналитические материалы рекламой не являются.
	Ответить | Правка | К родителю #409 | Наверх | Cообщить модератору

	430. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 04:09
	>Даже само утверждение "Rust - безопасный язык" - уже вводит потребителя в заблуждение, так как его безопасность ограничена только управлением памятью и потоками вне unsafe блоков, да и то не всегда. Но ведь в тексте новости именно об этом и говорится - Rust безопасен только в части работы с памятью, а не вообще везде и во всём. Или вы новость не удосужились прочитать, но мнение имеете?
	Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

	444. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 05-Апр-25, 13:39
	А при чём тут новость, если Вы оспариваете мое изначальное утверждение? https://www.opennet.dev/openforum/vsluhforumID3/136517.html#286
	Ответить | Правка | К родителю #430 | Наверх | Cообщить модератору

	460. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 22:50
	Ваше изначальное утверждение не несёт не содержит в себе фактов, это всего лишь ваше ничем не подкреплённое мнение (на которое вы, безусловно, имеете полное право), поэтому оспаривать его было бы неосмотрительно с моей стороны. Я отвечал именно на ваше последнее утверждение, где вы придумали что-то, а потом сами же начали это придуманное оспаривать.
	Ответить | Правка | К родителю #444 | Наверх | Cообщить модератору

	448. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 05-Апр-25, 16:21
	>> Вот на каком рынке идет продвижение раста? > Если хотите более точно, то на рынке языков программирования. Хм.. ну ок. Хотя рынок вроде есть, а вакансий на раст кот наплакал) Неужели ищут куда денег потратить? >> Прекрасно, когда автор статьи *призывает* перейти с винды на линукс > Не реклама, если не указывается конкретный дистрибутив или его производитель. Это если не упоминаются какие-то неправдивые сведенья. Например "винда шпионит" (есть же юр. термин) или "у нас свободная система, а у них нет". Вполне подходит под очернение конкурентов. > А вот тут начинается тонкий лёд. Почитайте https://secrets.tbank.ru/trendy/kak-ispolzovat-sravneniya-v-.../ Вот именно. Когда призывают вместо винды использовать ядро линукс (а оно у нас одно), то это на 100% реклама. То что там будут скинчики в виде ДЕ разные, мало волнуют. > Например, если обсуждая Rust говорить о CVE в каких-то продуктах на C, то с точки зрения Закона "О рекламе" совершенно некорректно не указать так же, что только в rust-std за последние пять лет было полтора десятка CVE. CVE-CVE рознь. В почти каждой статье про раст говорится про ошибки по по памяти, а не вообще все. > Даже само утверждение "Rust - безопасный язык" - уже вводит потребителя в заблуждение, так как его безопасность ограничена только управлением памятью и потоками вне unsafe блоков, да и то не всегда. Везде где я видел описание раста - там было что-то memory-safe language. > Посмотрите на инфраструктуру esp-rs https://github.com/esp-rs > Там этих unsafe блоков больше сотни в сумме наберется! Вы уверены, что это безопасно? Я вот уверен в обратном, так коммитил туда исправления ошибок, в том числе и при работе с памятью. Так фишка в том что в нем "хоть где-то безопасно". Но сомневаюсь, что адепты других ЯП запишут в стандарт что-то вроде "С totally memory unsafe". Это как автомобили - есть вольво с 9 подушками и копейка без единой. Можно говорить что вольво тоже не безопасный авто, тк не выдерживает столкновение с поездом, но имхо это безсмысленно > И наверняка таких ошибок там еще не мало осталось. Причем, подавляющее большинство исправленных мной ошибок было не в самих unsafe блоках. Например, при освобождении AdcContDriver в esp-idf-hal просто забыли остановить DMA. В результате тот продолжал хреначить данные с ADC в область памяти освобожденного буфера по кругу. > Нужно объяснять, к каким последствиям это приводило? Это же логическая ошибка? >> Меня даже забавляют ваши упорные попытки интерпретировать новости и обсуждение раста как рекламу)) > Где Вы это увидели? Я наоборот указал, что справочно-информационные и аналитические материалы рекламой не являются. Странно, разговор начался с "> В чем минус этого "буллет поинта" при продвижении языка? Именно в том, как он происходит. Для подавляющего большинства адекватных людей это выглядит, как упорная попытка всучить нольпроцентный кредит, в договоре которого мелкими буквами фиксируется чуть ли не продажа души дьяволу. Стиль точно такой же." Т.е продвижение языка сравнили с рекламой "практически неотличимо"
	Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

	452. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 05-Апр-25, 19:10
	> Вполне подходит под очернение конкурентов. Это называется антиреклама. > Когда призывают вместо винды использовать ядро линукс (а оно у нас одно), > то это на 100% реклама. Пользуйтесь WSL2? ))) > CVE-CVE рознь. С таким подходом, при обсуждении Rust, говорить о CVE или вообще недопустимо, или каждый надо сравнивать. Но CVE делят не по признаку, была ли ошибка при работе с памятью или нет, а по важности. Если реализация zip в rust до 19 марта могла потенциально молча заменить любой файл, доступный пользователю, под которым запущена программа, это лучше переполнения буфера, не приводящим ни к каким критичным проявлениям, кроме аварийного завершения программы? > В почти каждой статье про раст говорится про ошибки по по памяти, Мало что ли было только в rust-std CVE с ошибками при работе с памятью? За все годы только use-after-free больше трех десятков набирается. > а не вообще все. Вот и получается, что с очень большой вероятностью, в программе, которой 2-3 года от роду будет больше ошибок, чем в программе с 20-25 летним стажем использования. И то, что при программировании на Rust ошибок при работе с памятью получается в разы меньше, чем на том же C (методы безопасной работы с памятью в C пока оставим в покое), никак не уменьшает вероятность других ошибок. > Везде где я видел описание раста - там было что-то memory-safe language. При чем тут описание? > Так фишка в том что в нем "хоть где-то безопасно". Нигде, пока при разработке приходится использовать unsafe. Даже локализовать этот unsafe в нескольких библиотеках пока не представляется возможным. А уже контролировать все данные, которые могут быть использованы в unsafe блоках - это вообще малодостижимо. > Это как автомобили - есть вольво с 9 подушками Но в Rust, как и в любом другом языке программирования, случайно все эти 9 подушек можно отключить. Причем даже без unsafe, а просто некорректно считывая датчики ремней безопасности. >> И наверняка таких ошибок там еще не мало осталось. Причем, подавляющее большинство исправленных мной ошибок было не в самих unsafe блоках. Например, при освобождении AdcContDriver в esp-idf-hal просто забыли остановить DMA. В результате тот продолжал хреначить данные с ADC в область памяти освобожденного буфера по кругу. >> Нужно объяснять, к каким последствиям это приводило? > Это же логическая ошибка? Мда. Хорошо, объясняю. Если DMA хреначит данные с ADC в область память освобожденного буфера, то почти наверняка это приведет к краху программы. Особенно, если этот буфер был ранее аллоцирован в стеке. Поэтому, строго по определению, это уж никак не логическая ошибка https://ru.wikipedia.org/wiki/%D0%9B%D0%...) >> Очень редко попадается адекватное продвижения Rust, где честно и наглядно показываются все pros и cons. > Т.е продвижение языка сравнили с рекламой "практически неотличимо" Перечитайте, что я писал. Смотря какое продвижение.
	Ответить | Правка | К родителю #448 | Наверх | Cообщить модератору

	278. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 15:01
	>развёрнута масштабная кампания по дискредитации языка Си Си давным давно себя дискредитировал непрерывным потоком CVE >философии UNIX Которая себя дискредитировала ещё в момент появления. Вы хотя бы осознаёте насколько крива реализация того же fork-а, и к чему приводят костыли навешанные вокруг него? >и открытых систем Открытые системы - зло. Нужен свободный софт, а не чуть-чуть призакрытый.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	285. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от xsignal (ok), 04-Апр-25, 15:10
	> Си давным давно себя дискредитировал Это проблема не Си, а "эффективных менеджеров" со своими технологиями быстрой разработки и выкатыванием сырых продуктов по принципу "лишь бы раньше конкурентов". > Которая себя дискредитировала ещё в момент появления Ну конечно) Поэтому Линус Торвальдс взял её за основу своей ОС. UNIX - это лучшее, что появилось в мире IT за последние 100 лет!
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 15:30
	>> Си давным давно себя дискредитировал > Это проблема не Си, а "эффективных менеджеров" со своими технологиями быстрой разработки  и выкатыванием сырых продуктов по принципу "лишь бы раньше конкурентов". XOrg это уже "эффективные менеджеры" или еще "патриархы IT и гении программирования"? А жлиб? Sudo? Тысячи их!
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от xsignal (ok), 04-Апр-25, 15:53
	А что Xorg? Работает. Подарил Linux'у GUI. Без него все так на винде бы и сидели. Я с 2004 года под Xorg'ом и до сих пор, вообще никаких претензий.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 16:02
	> А что Xorg? Работает. VRR уже умеет? Виснуть намертво уже отучился? Жигули тоже ездят. Вроде. Как и телега. > Без него все так на винде бы и сидели. Так все и так сидят) Или винда или мак. Немножко хрома. 4% меньшинство было достигнуто в основном благодаря стимдеку. > Я с 2004 года под Xorg'ом и до сих пор, вообще никаких претензий. Кому и кобыла - невеста (с) Если тебя устраивают регулярные новости "Обновление X.Org Server ХХ.Х.Х с устранением N уязвимостей" В которых эти самые уязвимости живут по 30 лет, то я вопросов больше не имею) А вот люди которые туда макались, говорят про кривую архитектуру, "80 тыщ строк ужаса" и прочие забавные вещи.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (88), 04-Апр-25, 16:28
	У легкомысленных пиар-растов всё просто. Подумаешь какой-то X.Org Server, а они уж точно создадут "некривую" архитектуру. Трепещите! Напишут, перепишут, аж допереписываются, но только если корпы хорошо заплатят! Да, и вот такие потешные экземпляры корпоративно-либерастической культурки на полном серьёзе считают, что раст не задвинут, что это надолго. Как говорится, блаженны верующие, ибо они не ведают сомнения.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (311), 04-Апр-25, 16:44
	> У легкомысленных пиар-растов всё просто. Какая фантастическая чушъ. > Подумаешь какой-то X.Org Server, а они уж точно создадут "некривую" архитектуру. Ее и создали - с меньшей кривизной, называется вейланд протокол. А вот реализации есть и на СИ и на Расте. Понятно что любители монополий расстроились, но кого это волнует. > Трепещите! Напишут, перепишут, аж допереписываются, но только если корпы хорошо заплатят! Логично что заплатят. Вон в ядро корпы почти 90% кода пишут, почему бы за хорошую заботу не взять денег? > Да, и вот такие потешные экземпляры корпоративно-либерастической культурки на полном серьёзе считают, что раст не задвинут, что это надолго. Как говорится, блаженны верующие, ибо они не ведают сомнения. Ага, я уже слышал "да не возьмут раст в ядро")) И что? Что с лицом?))
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (88), 04-Апр-25, 17:19
	>> Да, и вот такие потешные экземпляры корпоративно-либерастической культурки на полном серьёзе считают, что раст не задвинут, что это надолго. Как говорится, блаженны верующие, ибо они не ведают сомнения. > Ага, я уже слышал "да не возьмут раст в ядро")) > И что? Что с лицом?)) Если поделие кое-как взлетит, то в будущем редизайн неизбежен. Теперешний раст - это всего лишь экспериментальная отработка теории, за которой последует нечто более вменяемое. Но возможен и худший сценарий - оставят ржаветь всё как есть. Про ядро - пока там ни о чём.
	Ответить | Правка | Наверх | Cообщить модератору

	431. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 04:20
	>Теперешний раст - это всего лишь экспериментальная отработка теории, за которой последует нечто более вменяемое. Ваше утверждение справедливо практически для любого языка программирования. Поэтому, спасибо, Кэп, но Америку открыть у вас не получилось, увы.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 16:44
	>Я с 2004 года под Xorg'ом и до сих пор, вообще никаких претензий HDR, HiDPI, разная плотность пикселей, аппаратное ускорение во вложенном сервере, и куча других вещей - недоступна в Xorg, либо работает с проблемами.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	296. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 15:45
	> Вы хотя бы осознаёте насколько крива реализация того же fork-а Не осознаю. Чем создание дочернего процесса через fork() c CoW хуже, чем с копированием памяти при создании процесса? Если нужен именно дочерний процесс, который никаким образом не может повлиять на родительский или братский, и крах которого будет крахом только его одного, то fork() очень эффективен. Просто не надо пользоваться fork() там, где нужны нити.
	Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

	308. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 16:30
	>Чем создание дочернего процесса через fork() c CoW хуже, чем с копированием памяти при создании процесса? Когда у вас памяти 640 Кб (или сколько там было), то это может быть и выглядит хорошо. Проблемы начинаются на современных машинах. Во-первых, копировать память дорого, из-за чего возникает первый костыль - CoW. Во-вторых совершенно внезапно и совершенно непредсказуемо возникает вторая проблема: форкнутся может только процесс, который более чем вдвое меньше свободной оперативной памяти. И теперь либо нужен костыль, когда жирные процессы содержат специальный родительский процесс, нужный только для нужд форка, что довольно неудобно, но зато работает, либо появляется оверкоммит. В-третьих, с появлением оверкоммита совершенно непонятно, сколько памяти в системе свободно, а сколько - занято, так как из-за CoW даже запись в уже выделенный массив может привести к росту потерблённой памяти. Из-за этого размер виртуальной памяти перестаёт хоть как-то контролироваться, и malloc всегда вернёт указатель, даже если запросить больше чем вся оперативная память. Программы теряют возможность хоть как-то обнаружить нехватку памяти в системе. В-четвёртых из-за того, что программы могут без проблем запросить больше памяти, чем есть в системе, а работать без памяти они не могут, это приводит к новому костылю - ядерному OOM киллеру, так как если памяти больше нет, то единственный способ её добыть - убить какой-то процесс. В пятых, поскольку убийство процесса может произойти в абсолютно любом месте, это рождает целую гроздь проблем: любую программу нужно писать особо устойчивой, например, использовать базу данных с поддержкой транзакций, вместо текстовых файлов, максимально избегать работы с несколькими файлами, так как транзакций на уровне файловых систем почему-то нет, делать особые трюки с файловыми путями, чтобы остальные операции были максимально атомарными, это только на уровне файлов, а есть же ещё и сетевые соединения и куча всего остального. В-пятых поскольку убийство программы оом киллером приводит к порче данных, то дождаться ядерного ООМ киллера будет проблематично, сервер может и дождётся, а вот десктоп точно зависнет, что приведёт к юзерспейсному ООМ киллеру. Ну и в шестых, юзерспейсный ООМ киллер подобен слону в посудной лавке, и далее его нужно долго обучать, что sshd лучше не трогать, как и блокировку экрана, как и кучу других вещей. >Если нужен именно дочерний процесс, который никаким образом не может повлиять на родительский или братский, и крах которого будет крахом только его одного, то fork() очень эффективен Нет. Единственная причина, почему существует fork - это нежелание в прошлом набирать символы на клавиатуре. Если fork есть, то для реализации консольного chroot упрощённо будет fork без аргументов, потом chroot с одним единственным аргументом - строкой, переиспользующий уже существующий вызов chroot, возможно chdir с одним аргументом, потом execv с двумя аргументами, аналогично переиспользующий существующий код. Если fork-а нет, то будет либо огромный create_process, с какой-то сложной структурой(привет обратная совместимость), который будет будет с нуля под копотом реализовывать половину остальной системы, типа chroot, chdir, и кучу всего остального, либо понадобится каким-то образом научить chroot(и остальные вызовы) работать не только с текущим процессом, но и с только что созданным дочерним. >Просто не надо пользоваться fork() там, где нужны нити. По хорошему, fork вообще не надо использовать, но вот беда, если не говорить про исследовательские разработки, то из свободного/открытого кода есть только ReactOS, застрявшая в вечной альфе
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 17:39
	>>Чем создание дочернего процесса через fork() c CoW хуже, чем с копированием памяти при создании процесса? > Во-первых, копировать память дорого, из-за чего возникает первый костыль - CoW. Не понял, а почему это костыль и какие альтернативы есть без fork()? Ну кроме как раз копирования памяти, который fork() позволяет избежать. > Во-вторых совершенно внезапно и совершенно непредсказуемо возникает вторая проблема: форкнутся может только процесс, который более чем вдвое меньше свободной оперативной памяти. С какого перепугу? С виртуальной памятью не перепутали? Понаблюдайте как форкается PostgreSQL на каждое соединение. У меня есть сервер с 256 ГБ RAM, где часто вижу в памяти и 1000+ процессов postgres по 70 ГБ виртуальной памяти ~= 70 ТБ. И всё великолепно работает. > И теперь либо нужен костыль, когда жирные процессы содержат специальный родительский > процесс, нужный только для нужд форка А зачем? Родительский процесс независим от дочернего и может спокойно завершить работу. Linux kernel так и инициализируется. А вот с нитями такой номер уже точно не пройдет. > В-третьих, с появлением оверкоммита Так в том то и дело, что overcommit при fork() не возникает, чего не скажешь про нити. > из-за CoW даже запись в уже выделенный массив может привести к росту потерблённой памяти. И это замечательно, так как RAM используется более эффективно. > В-четвёртых из-за того, что программы могут без проблем запросить больше памяти, чем есть в системе, а работать без памяти они не могут И это тоже замечательно и управляемо. В результате PostgreSQL может параллельно обслуживать чуть ли не на порядок больше соединений, чем MS SQL. Случаи, когда планировщик сжирает на порядок больше оперативки, чем реально требуются запросу - дело обычное. Даже с терабайтом оперативки я на MS SQL порой вижу очередь запросов, ожидающих память из-за ошибки планировщика. На PostgreSQL таких проблем нет. > В пятых, поскольку убийство процесса может произойти в абсолютно любом месте Так же, как в любом месте без CoW может закончиться память. И даже открыть файл после этого может не получиться. > десктоп точно зависнет Для десктопа, где заранее расчитать потребность в RAM проблематично, есть swap. При достаточном его объеме никакой OOM Killer не страшен. >  Ну и в шестых, юзерспейсный ООМ киллер подобен слону в посудной лавке, и далее его нужно долго обучать Все средства для этого есть. >>Если нужен именно дочерний процесс, который никаким образом не может повлиять на родительский или братский, и крах которого будет крахом только его одного, то fork() очень эффективен > Нет. Если бы не fork(), то предоставить хранимые процедуры и функции на Rust или Python я бы аналитикам просто не смог, так как паника в Rust или исключение в Python периодически приводили бы к краху всего PostgreSQL (как это происходит порой с CLR в MS SQL). А так аналитик рискует исключительно собственным соединением. В MS SQL для избежания краха всего сервера реализована работа sp_execute_external_script() через LaunchPad, что пожирает в среднем 30 мс на каждый вызов. Для сравнения, в PostgreSQL вызов plpythonu или plrust вписывается в 10 мкс. Три порядка - дорогая цена.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 18:58
	>Не понял, а почему это костыль и какие альтернативы есть без fork()? Об этом написано в самом конце оригинального сообщения. >Ну кроме как раз копирования памяти, который fork() позволяет избежать. fork не позволяет избежать копирования памяти, fork позволяет копировать память лениво вместо жадных реализаций из первых юниксов. >С какого перепугу? С виртуальной памятью не перепутали? >У меня есть сервер с 256 ГБ RAM, где часто вижу в памяти и 1000+ процессов postgres по 70 ГБ виртуальной памяти ~= 70 ТБ. Работает только до тех пор, пока эти процессы почти не меняют память родительского процесса. Выделите в родительском процессе 5 Гб буфер и заполните его нулями, для вашего объёма это смешной размер. Запишите его размер. Сделайте для примера 100 форков. Вот здесь у вас потребление памяти почти не изменится, процессы - лёгкие. Начните в каждом форке заполнять этот буфер значением, равным номеру форка - в первом форке - единицами, во втором - двойками и так далее. Сработает CoW, и не смотря на то, что сейчас будет что-то вроде ``` for (size_t i = 0; i < arr_size; i += 4096) {     arr[i] = fork_num; } ``` То вы тут же заметите, как объём доступной памяти начал сокращаться, не смотря на то, что ни одного явного выделения памяти нет. Поскольку каждая новая запись происходит в новую страницу, то вы увидите быстрое падение доступной памяти, которая исчерапает все доступные вам ресурсы. >В результате PostgreSQL может параллельно обслуживать чуть ли не на порядок больше соединений, чем MS SQL. Случаи, когда планировщик сжирает на порядок больше оперативки, чем реально требуются запросу - дело обычное Вам повезло в плане характера нагрузки. А теперь попробуйте на десктопе запустить игру в один процесс, так, чтобы игра потребляла почти всю свободную оперативку. Если вам повезёт, то игра будет периодически подлагивать, когда памяти будет мало(условно 100 Мб свободных), если не повезёт, то игра намертво зависнет, вместе с системой. Вы не сможите её закрыть ни по Alt+F4, ни переключится на соседнее окно - ничего. Разве что сработает юзерспейсный ООМ, который скорее всего по умолчанию не стоит >А зачем? Родительский процесс независим от дочернего и может спокойно завершить работу Например, доступно 6 Гб оперативки. Запускается IDE, которая в процессе работы потребляет 3.5 Гб. Если я хочу в IDE открыть терминал, то 3.5+3.5 > 6, и fork не проходит. Но, с появлением оверкоммита система система позволяет вызвать fork, а поскольку за fork-ом идёт exec, то новый процесс не успевает занять в физической памяти все свои 3.5 Гб. Если будет родительский процесс, то будет условно 10 Мб родительский процесс, 3.5 Гб IDE, для запуска терминала 10 Мб + 10 Мб + 3.5 Гб < 6 Гб, fork проходит даже без оверкоммита. >>из-за CoW даже запись в уже выделенный массив может привести к росту потерблённой памяти. >И это замечательно, так как RAM используется более эффективно. Проблема не в ленивом копировании памяти, а в том, что и fork, и malloc не проверяют доступный объём. Сначала программе дают сколь угодно много памяти, а потом если ей не достанется физической - её прибьют >И это тоже замечательно и управляемо Это не управляемо. Я никак не могу проверить, есть ли в системе ещё память или уже всё. >В результате PostgreSQL может параллельно обслуживать чуть ли не на порядок больше соединений, чем MS SQL Для сравнения нужно брать одинаковые программы, а не разные. Я не знаю, чем они отличаются под капотом, кроме использования fork-а. Как минимум, нужно сравнить постгрес на видне и на линуксе, но и то, могут быть какие-то ещё различия >Так же, как в любом месте без CoW может закончиться память Память заканчивается не из-за CoW, а из-за оверкоммита. >И даже открыть файл после этого может не получиться. Вы понимаете разницу, между тем, что malloc вернёт null, когда можно запустить сборку мусора, начать аварийное сохранение данных, да даже вывести модальное окно "память закончилась, освободите память и нажмите Enter и тем, что вашему процессу прилетит 9-ый сигнал, который нельзя обработать? >Для десктопа, где заранее расчитать потребность в RAM проблематично, есть swap. Swap это не решение, это - костыль. Вы попробуйте игре объяснить, что память закончилась, остался только своп, и fps упадёт до неспешного слайдшоу, один кадр в несколько минут, а если повезёт то между кадрам может пройти несколько часов, а то и больше. Мне очень интересно на это посмотреть >При достаточном его объеме никакой OOM Killer не страшен Так в этом и проблема, что unix по определению работает только в том случае, если есть большой запас по доступной памяти. И если у вас иногда случаются лёгкие нехватки памяти, то всё, нужно бежать менять железо >Все средства для этого есть Средств для этого нет. Рекомендую ознакомится с деятельностью https://www.linux.org.ru/people/hakavlad/profile. Если нужно решить проблему на десктопе, то нужны особые патчи ядра(которые могут молча отвалится в новом релизе), oom киллер, prelockd, особые конфиги cgroups, ещё какая-то магия, тонный хрупких костыльных конфигов, которые поломаются если вместо gnome использовать mate и наоборот и это всё может быть будет немного работать, но только немного. Из коробки ничего этого нет. А вот решили воткнуть решение из коробки, лечат головную боль гильотиной https://www.linux.org.ru/forum/desktop/16229420 >Если бы не fork(), то предоставить хранимые процедуры и функции на Rust или Python я бы аналитикам просто не смог, так как паника в Rust или исключение в Python периодически приводили бы к краху всего PostgreSQL Спасибо, я понимаю, чем fork отличается от порождения ещё одного потока внутри текущего процесса >В MS SQL для избежания краха всего сервера реализована работа sp_execute_external_script() через LaunchPad Ещё раз говорю, не надо сравнивать столь разные системы. Тут нужно сравнивать примерно на уровне сишных hello world-ов.
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 20:16
	>>Не понял, а почему это костыль и какие альтернативы есть без fork()? > Об этом написано в самом конце оригинального сообщения. Не вижу. Предложение на каждое новое соединение запускать весь PostgreSQL выглядит несколько бредовым. А каки минусы в нитях я очень популярно изложил. >>Ну кроме как раз копирования памяти, который fork() позволяет избежать. > fork не позволяет избежать копирования памяти, fork позволяет копировать память лениво > вместо жадных реализаций из первых юниксов. Собственно говоря это и позволяет PostgreSQL быстро создавать новые соединения в независимых процессах. >>С какого перепугу? С виртуальной памятью не перепутали? >>У меня есть сервер с 256 ГБ RAM, где часто вижу в памяти и 1000+ процессов postgres по 70 ГБ виртуальной памяти ~= 70 ТБ. > Работает только до тех пор, пока эти процессы почти не меняют память > родительского процесса. Пусть меняют. В случае PostgreSQL они всё равно ограничены конфигурацией сервера и больше сожрать не смогут. Опять возвращаемся к тому, что для fork() и нитей области применения РАЗНЫЕ. > Вам повезло в плане характера нагрузки. А теперь попробуйте на десктопе А зачем? Сама идеология fork() и OOM Killer направлена, в первую очередь, для серверной нагрузки. Зачем пользователю на десктопе гарантия, что порожденные fork() подобные процессы независимы и крах одного из них не вызовет крах всех остальных? Я уже несколько раз указывал, что fork() нужен для изоляции процессов, обслуживающих разных пользователей. Зачем Вы упорно возвращаетесь к сценирию, в котором fork() просто не нужен? > Это не управляемо. Я никак не могу проверить, есть ли в системе > ещё память или уже всё. Вы вполне можете это сделать при конфигурации сервера. Причем никто не запрещает Вам запускать там процессы в индивидуальных контейнерах, для которых объем памяти строго ограничен. Более того, именно так и следует поступать. >>В результате PostgreSQL может параллельно обслуживать чуть ли не на порядок больше соединений, чем MS SQL > Для сравнения нужно брать одинаковые программы, а не разные. Я взял программы, которые способны выполнять одни и те же функции. > нужно сравнить постгрес на видне и на линуксе Смысл? Ну увидите в очередной раз деградацию производительности под Windows. Что это даст? >>Так же, как в любом месте без CoW может закончиться память > Память заканчивается не из-за CoW, а из-за оверкоммита. Память в любом случае может закончится. Разница лишь в том, что без CoW она закончится у случайного процесса и он сам будет пытаться как-то выкручиваться. И если он сразу же не грохнет себя, то возможна цепная реакция с крахом целого ряда процессов. Под Windows я такое наблюдал неоднократно. В случае же CoW OOM Killer прибьет наименее важный процесс в соответствии с указаниями пользователя. Именно это я и называю управляемостью. >>И даже открыть файл после этого может не получиться. > Вы понимаете разницу, между тем, что malloc вернёт null, когда можно запустить > сборку мусора, начать аварийное сохранение данных, Особенно если память действительно закончилась и её недостаточно даже для открытия файла ))) > да даже вывести модальное окно "память закончилась, освободите память и нажмите Enter С каких пор окну не нужна память? отать? >>Для десктопа, где заранее расчитать потребность в RAM проблематично, есть swap. > Swap это не решение, это - костыль. Вы попробуйте игре объяснить А зачем ей что-то объяснять? Запустил htop, оценил ситуацию и сам решил, что штатным образом следует закрыть. Может это забытый DBEaver гигабайт восемь сожрал? > Так в этом и проблема, что unix по определению работает только в > том случае, если есть большой запас по доступной памяти. Вы уж простите, но с Windows тут проблем намного больше. Если на сервере с Linux и PostgreSQL, ClickHouse или даже с MS SQL for Linux я могу совершенно не беспокоясь запускать какие-то процессы, точно зная, что OOM Killer в случае чего пришибет именно их, а не СУБД, то под Windows - это совершенно непредсказуемо. Вообще странное утверждение, что в системе, где неиспользуемая, но аллоцированная память всегда коммитится, потребление памяти будет ниже, чем в системе, где неиспользуемая, но аллоцированная память не откоммитится никогда. Вообще-то получается с точностью наоборот ) >>Все средства для этого есть > Средств для этого нет. Кто мешает управлять oom_score или даже запретить overcommit, если принципиально не хочется руками закрывать ненужные приложения, после ухода в swap? > Спасибо, я понимаю, чем fork отличается от порождения ещё одного потока внутри > текущего процесса Не вижу, так как не предложили альтернативу для моего примера с PostgreSQL. >>В MS SQL для избежания краха всего сервера реализована работа sp_execute_external_script() через LaunchPad > Ещё раз говорю, не надо сравнивать столь разные системы. Почему? Я сравниваю две СУБД, более-менее подобные по функциональности. MS SQL - один многопоточный процесс, а PostgreSQL - по процессу на каждое соединение. И я на пальцах показал, как это различие влияет в весьма распространенном сценарии использования СУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 22:16
	>Не вижу В данном вопросе, создание процесса в windows стиле выглядит куда более привлекательным. >А каки минусы в нитях я очень популярно изложил Не изложили. В данном случае рядом с постгресом можно запустить ещё один процесс, например, всё тот же python, который будет работать как фронтенд, если вы так не хотите встравивать код интерпретатора в оригинальный процесс. >Собственно говоря это и позволяет PostgreSQL быстро создавать новые соединения в независимых процессах. Процессы постгреса не являются независимыми. >Пусть меняют. В случае PostgreSQL они всё равно ограничены конфигурацией сервера и больше сожрать не смогут Я привёл вам пример, как с гораздо меньшим размером виртуальной памяти и меньшим количеством процессов исчерпать всю доступную память. Вы упорно это игнорируете >Сама идеология fork() и OOM Killer направлена, в первую очередь, для серверной нагрузки Осталось только понять, чем серверные нагрузки отличаются от не серверных. php это ещё серверная нагрузка или уже нет? Уже здесь вы не сможете так же легко сказать, сколько процессов php будет запущено, тем более, когда у вас появятся очереди и прочие вещи >Зачем пользователю на десктопе гарантия, что порожденные fork() подобные процессы независимы и крах одного из них не вызовет крах всех остальных? Затем, что сразу же после загрузки init-а, вам нужно запустить что-то отличное от этого самого init-а. Даже более того, можно открыть условный файловый менеджер, запустить из него программу, а потом файловый менеджер закрыть. Вы почему-то ограничиваетсь дихтомией fork или нить, словно не существует других вариантов. Про те же зелёные потоки вы не вспоминаете. Кроме того, для порождения процессов могут использоваться разные апи. Посмотрите на апи той же фуксии, там тоже нет форка, там процессы порождаются по другому. >Зачем Вы упорно возвращаетесь к сценирию, в котором fork() просто не нужен? Затем, что альтернатив fork-у нет. Вот просто нет ещё одного вызова, который бы обладал другой семантикой >Вы вполне можете это сделать при конфигурации сервера Это легко сделать только в тривиальных случаях, когда у вас на сервере один только постгрес. А когда у вас на сервере крутится куча всего: постгрес, какой-то бекенд, несколько брокеров, гитлаб или альтернатива, ci/cd, то это резко теряет в управляемости. Вы уже не сможете распределить память между всеми процессами, на одном будет избыток, на втором - недостаток. >Я взял программы, которые способны выполнять одни и те же функции. У меня складывается впечатление, что вы либо пользователь, либо сисадмин. Сравнивать нужно максимально похожие программы, кроме вызова fork, вплоть до того, что взять условный minix, и добавить ему ещё один(или несколько) системных вызовов, чтобы запускать их даже под одним и тем же ядром. У вас слишком много переменных, очень легко промазать. Даже банально запусти хранимую процедуру в предзапущенном процессе, обмен данными с которым будет через сокет, уже латентность на порядки изменится. >Разница лишь в том, что без CoW она закончится у случайного процесса и он сам будет пытаться как-то выкручиваться В случае отсутствия оверкоммита процесс может выкрутится. В случае присутствия - не может. Вы с этим согласны? >В случае же CoW OOM Killer прибьет наименее важный процесс в соответствии с указаниями пользователя Проблема в том, что важность эту нужно вручную настраивать на каждой машине. Для сервера важность одна, для машины разработчика - другая. Это никак не масштабируется. На подавляющем количестве машин таких настроек вообще нет, и улетает первый попавшийся процесс. По ссылке выше обсуждалась, как улетает сразу вся графическая сессия. Это не говоря уже про то, что сразу же после этого нужно будет так же вручную заниматься логикой перезапуска всего упавшего, поскольку если особенно повезёт, оом киллер убъёт и тот же постгресс, но не тронет php-fpm и система превратится в тыкву. >Особенно если память действительно закончилась и её недостаточно даже для открытия файла Вы не допускаете, что программа может при старте зарезервировать какой-то объём на экстренные нужды, в том числе открыть какой-то файл? Вы не допускаете, что программа может начать штатное завершение работы, например, удалить временные файлы? >Запустил htop, оценил ситуацию и сам решил, что штатным образом следует закрыть А ещё, у меня есть подозрение, что вы linux только на серверах и видели. Если у вас игра съест всю память, то у вас будет условно секунда, чтобы среагировать, после чего зависнут все программы. Игра, htop, терминал, в котором запущен htop, иксы или вейленд, ssh, и всё остальное. Работать будет только ядро. Если особенно повезёт, то нажимая на клавиатуре на опеределённую комбинацию можно на заблокированном устройстве обрушить все процессы, вплоть до условного ssh. И если ssh перезапустится, то графическая сессия - нет. Я однажды поймал нехватку память на сервере, там не было иксов и было чуть лучше: существующее подключение по ssh работало, пока не порвалось из-за сетевых проблем, а вот новое подключение создать уже не получалось. Скрипты для штатной остановки падали с ошибкой, пришлось просить админов ребутнуть сервак. Для этого нужно физически идти к серверу, или перезапускать из гипервизора. Если так упадёт домашний сервак, то едь через полгорода. >потребление памяти будет ниже Я не говорю про то, что будет ниже. Я говорю про то, что там всегда будет понятно, сколько памяти действительно свободно, а сколько - занято. На линуксе можно на ровном месте получить всплеск потребления памяти. И программа испарится посередине операции только по тому, что кончилась память. >Кто мешает управлять oom_score Ещё раз повторю - это нужно настраивать, при чём для каждой машины отдельно. Если у меня есть сервер и десктоп, то это две отдельные системы, я не могу скопировать конфиг из одного места в другую. Если добавить к этом ноутбук, то это, внезапно, третья конфигурация, если количество ядер и оперативки отличается. Это уже не говоря про ситуации, когда открыл одну страницу в браузере, и весь браузер был убит. Или запустил какой-то процесс, и браузер опять же убит. А если запускать сборку условного хрома, то там нужно будет вручную указывать количество ядер. >или даже запретить overcommit А теперь откройте монитор процессов и посмотрте на размер виртуальной памяти. Hello world на go потребляет 1 Гб виртуальной памяти сразу на старте. Прямо сейчас у меня pipewire-pulse потребялет ~486 Мб виртуальной памяти при ~90 Мб резидентной, konsole - 1.1 Гб виртуальной, при 77 Мб резидентной. Я вообще не уверен, что на ноутбуке с 8 Гб памяти вы сможете загрузится в графику, а даже если и сможете, то откроете терминал с гошным приветом, и память иссякнет. Это тупик, порождённый архитектурой unix. >если принципиально не хочется руками закрывать ненужные приложения, после ухода в swap? swap хорош, когда в него сложили какое-то количество страниц, и не трогают, хотя бы несколько минут. В противном случае, у вас каждая итерация цикла ``` for (size_t i = 0; i < arr_size; i += 4096) {     arr[i] = fork_num; } ``` будет ходить в своп, протирать в нём дырку и жутко тормозить. Особенно хорошо, когда кроме самого приложения в своп пойдёт графика. Никаких вариантов сказать программе, что память закончилась - нет, можно только позвать оом киллер. >Не вижу, так как не предложили альтернативу для моего примера с PostgreSQL Вы не понимаете, чем отличается системный вызов и база данных, делающая тысячи разных системных вызовов? Кроме того, вы пишите, что размер процесса - 70 Гб. Осталось определить, действительно ли каждому процессу нужны эти 70 Гб, а что если я подключился, сделал select version(); select count() from products; и отключился? В крайнем случае есть prefork, как это сделано в том же apach. >Почему? Я сравниваю две СУБД, более-менее подобные по функциональности. MS SQL - один многопоточный процесс, а PostgreSQL - по процессу на каждое соединение. И я на пальцах показал, как это различие влияет в весьма распространенном сценарии использования СУБД. Ещё раз, это разные вещи. Вот есть китайфон, с 3.5 разъёмом для наушников, который делает плохие снимки, и есть iphone, в котором нет разъёма для наушников, который делает хорошие снимки. Следуя вашей логике, разумно предположить, что проблемам со снимками мешает 3.5 разъём, так как он есть на китайфоне, и нет ни на iphone. Проблема в том, что на качетсво снимков влияют и другие факторы, и нужно для сравнения взять Сони, Сяоми, и так далее, которые делает хорошие снимки, и имеют разъём для наушников. И тогда обнаружится, что хорошие снимки можно делать как с 3.5 раъёмом, так и без него, а разница обусловлена чем-то другим, например камерой. Так вот, если сравнивать nginx и apach, то преимущество будет почему-то не на строне apach-а, который обрабатывает соединения в отдельном процессе. И определить, что выиграет - база данных на языке с асинхронностью и зелёными потоками или база данных поверх fork-ов  - сложно
	Ответить | Правка | Наверх | Cообщить модератору

	410. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от ptr (ok), 04-Апр-25, 23:00
	>>Не вижу > В данном вопросе, создание процесса в windows стиле выглядит куда более привлекательным. И как технически Вы это собрались реализовать? Копированием всех 70 ГБ? Ведь несмотря на то, что work_mem лишь 100M, Вы без понятия, где они будут в этих 70 ГБ. >>А каки минусы в нитях я очень популярно изложил > Не изложили. В данном случае рядом с постгресом можно запустить ещё один > процесс, например, всё тот же python, который будет работать как фронтенд, > если вы так не хотите встравивать код интерпретатора в оригинальный процесс. И опять те же проблемы, так как если этот процесс грохнется, то это отразится на всех соединениях. >>Собственно говоря это и позволяет PostgreSQL быстро создавать новые соединения в независимых процессах. > Процессы постгреса не являются независимыми. Я такой догмой не знаком. Это из Корана или Библии? >>Пусть меняют. В случае PostgreSQL они всё равно ограничены конфигурацией сервера и больше сожрать не смогут > Я привёл вам пример Вы намерено приводите примеры, где нити эффективней fork(). Или Вы подменяете понятия, или Ваша квалификация не позволяет это увидеть. > Вы упорно это игнорируете Наоборот. Я изначально написал, что у fork() и нитей разные области применения. А Вы тут машете нитями, как "золотым молотком" ))) >>Сама идеология fork() и OOM Killer направлена, в первую очередь, для серверной нагрузки > Осталось только понять, чем серверные нагрузки отличаются от не серверных. Они или предсказуемы, или могут быть искусственно ограничены средствами k8s. > php это ещё серверная нагрузка или уже нет? Да без разницы. Засовывайте сервис в pod и ограничивайте его там, как требуется. В любом случае, он там будет один и только сам на себя сможет повлиять. > Затем, что сразу же после загрузки init-а, вам нужно запустить что-то отличное > от этого самого init-а. Даже более того, можно открыть условный файловый > менеджер, запустить из него программу, а потом файловый менеджер закрыть. Вы > почему-то ограничиваетсь дихтомией fork или нить, словно не существует других вариантов. Вы искренне считаете, что при запуске того же файлового менеджера не происходит fork()? Shell не выполняет fork() только если задана - его внутренняя команда. Во всех остальных случаях он сначала выполняет fork()/vfork(), а уже порожденный процесс выполнит exec(). > Про те же зелёные потоки вы не вспоминаете. Это тоже нити. > Кроме того, для порождения процессов могут использоваться разные апи. Посмотрите на апи той же > фуксии, там тоже нет форка, там процессы порождаются по другому. Ну так она никогда и не была ориентировна на сервера. Более того, у Flutter таких проблем нет, так как он использует JIT компиляцию. >>Зачем Вы упорно возвращаетесь к сценирию, в котором fork() просто не нужен? > Затем, что альтернатив fork-у нет. Наконец-то >>Вы вполне можете это сделать при конфигурации сервера > Это легко сделать только в тривиальных случаях, когда у вас на сервере > один только постгрес. А когда у вас на сервере крутится куча > всего: постгрес, какой-то бекенд, несколько брокеров, гитлаб или альтернатива, ci/cd, > то это резко теряет в управляемости. > Вы уже не сможете распределить > память между всеми процессами, на одном будет избыток, на втором - > недостаток. Про k8s Вы слышите впервые? >>Я взял программы, которые способны выполнять одни и те же функции. > У меня складывается впечатление, что вы либо пользователь, либо сисадмин. Это радует. Если оппонент вынужден применить демагогию и переходить на личности, то дискуссию можно считать завершенной. Прощайте.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 05-Апр-25, 01:29
	>И как технически Вы это собрались реализовать? Копированием всех 70 ГБ? В первую очередь нужно определеить, сколько из 70 Гб этих данных реально нужны этому процессу >И опять те же проблемы, так как если этот процесс грохнется, то это отразится на всех соединениях. Сейчас не 70-ые, чтобы переживать из-за каждого упавшего процесса. Управляемые языки, rust, да даже санитайзеры довольно хорошо поднимают аптайм >Я такой догмой не знаком Утверждение о том, что CoW всё-таки копирует память вы до сих пор игнорируете >> Вы упорно это игнорируете >Наоборот. Я изначально написал, что у fork() и нитей разные области применения. А Вы тут машете нитями, как "золотым молотком" ))) Вопрос не в эффективности. Вопрос в подсчёте занятой памяти >или могут быть искусственно ограничены средствами k8s Если вы считаете убийство процессов нормальным, то с этого и следовало начинать >Вы искренне считаете, что при запуске того же файлового менеджера не происходит fork()? Не считаю, о чём прямо пишу >Да без разницы. Засовывайте сервис в pod и ограничивайте его там, как требуется. В любом случае, он там будет один и только сам на себя сможет повлиять. Хорошо, предположим есть микросервис на голанге и микросервис на пхп. Как вы настроите поды так, чтобы при дефиците памяти из одного микросервиса он мог брать память из другого? >Это тоже нити. Они не управляются операционной системой, и должны быть написаны особым образом, иначе застрянут на блокирующем вызове >Ну так она никогда и не была ориентировна на сервера Разумеется, все юниксы предназначены исключительно для сервера, особенно макось и андроид. >> Затем, что альтернатив fork-у нет. >Наконец-то Нет никакого наконец-то. Это костатация факта, что другие вызова не реализованы, а не утверждение, что их нельзя реализовать или они не нужны >Про k8s Вы слышите впервые? Что вы хотите сказать, называя случайные программы? >Прощайте Большое спасибо, за отсутствие конкретики, это так хорошо утверждает вашу точку зрения
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Нуину (?), 04-Апр-25, 17:30
	Все верно написали. > причём раскрутка ведётся разветвлённой сетью раст-миссионеров Самое интересное, что ни в С, ни в С++, думаю даже в Расте они не разбираются.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	232. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Аноним (310), 04-Апр-25, 13:42
	>буквально насильно, пытаются его "популяризировать" Это потому, что разработчики у него впопулярные.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	240. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 13:54
	> Не разбираюсь в качестве языка, однако, что меня отталкивает в rust - это то, с какой маниакальной настойчивостью, буквально насильно, пытаются его "популяризировать". У тебя какое-то предвзятое отношение) > Нет такого, как с Go(из новых языков), когда разработчики решают: "О, прикольный язык, напишу пожалуй свою утилиту/программу на нём." Полно. Начиная от всяких вейланд композеров, заканчивая попытками в игровые движки. > Разработчики на Rust почему-то хотят не что-то новое создавать на этом языке, а именно переписать старое. Потому что они получили инструмент, который решает часть старых проблем. Это как сменить зубило на перфоратор) Самое классное, когда к такому приходят сами авторы проектов. Например создатели ARTI (который ТОР). > Почему-то мне кажется, что их психологический профиль совпадет с таковым у сторонников "декоммунизации" и подобного. Ага, а еще "любителей" выкидывать мусор, а не хранить завонявшийся хлам в квартире. И любители выкидывать коптящий пазик и заменить на нормальный автобус...
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	274. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 14:58
	>это то, с какой маниакальной настойчивостью, буквально насильно, пытаются его "популяризировать" Любую хорошую технологию нужно продвигать, иначе никто о ней не узнает, автор так и будет в одиночку десятилетиями её делать >Нет такого, как с Go(из новых языков), когда разработчики решают: "О, прикольный язык, напишу пожалуй свою утилиту/программу на нём." Вы совершенно не заметили всего того хайпа, когда голанг активно форсился, а любые указания на его недостатки отвергались по религиозным причинам. Когда его пытались засунуть буквально везде. Кроме того, для того, чтобы на языке что-то писали, для этого должна быть довольно веская причина. Вот вам  Standard ML, когда вы пойдёте на нём что-то писать? Даже если взять Ocaml, то когда вы на нём будете писать? >Разработчики на Rust почему-то хотят не что-то новое создавать на этом языке, а именно переписать старое. Аналогично, вы лицемерно игнорируете кучу историй о том, как на голанг переписывали с других языков программирования. Кто-то так и не смог переписать, и тоже писал статьи об этом.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	353. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (321), 04-Апр-25, 18:43
	> Любую хорошую технологию нужно продвигать Не нужно. Действительно нужное принимается быстро и без агрессивного маркетинга. Например, никто не носится по интернету с воплями о якобы ненужности ext4 и безальтернативно безупречной btrfs. У btrfs есть много полезных функций. Её просто используют и всё. О ней знают без навязывания.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (-), 04-Апр-25, 18:52
	>> Любую хорошую технологию нужно продвигать > Не нужно. Действительно нужное принимается быстро и без агрессивного маркетинга. Хм.. именно поэтому у линукса на дестопе доля в 4%?)) > Например, никто не носится по интернету с воплями о якобы ненужности ext4 и безальтернативно безупречной btrfs. Про "безальтернативно безупречной" это ты сам выдумал? Но ЧСХ в интернете куча статей EXT4 vs BTRFS linux.org/threads/ext4-vs-btrfs.39755/ Ext4, btrfs, or other, what difference and which is the best file system? forum.endeavouros.com/t/ext4-btrfs-or-other-what-difference-and-which-is-the-best-file-system/43266/1 why use Btrfs over Ext4? reddit.com/r/openSUSE/comments/8hwlr4/why_use_btrfs_over_ext4/ > У btrfs есть много полезных функций. Её просто используют и всё. О ней знают без навязывания. Вот сразу проснулись утром и узнали? Или таки была "реклама" в стиле вот новая крутая система. А вот и рекламные статьи linuxfoundation.org/blog/blog/a-conversation-with-chris-mason-on-btrfs
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (164), 04-Апр-25, 19:13
	>Действительно нужное принимается быстро и без агрессивного маркетинга. Ни разу такого не наблюдал >Например, никто не носится по интернету с воплями о якобы ненужности ext4 Рекомендую посмотреть на bcachefs, там что ни новость, так очередная драмма. То релизы Линусу портят, то в Дебиане не собирается, то автора отстранят. >Её просто используют и всё Полтора землекопа. Приходишь к хостинг провайдеру, а у него ext4. Приходишь на работу, а том тоже ext4, скачиваешь не новомодную убунту, а какой-нибудь консервативный дистрибутив, и там, внезапно, тоже ext4. Справшиваешь на работе, а нельзя ли сделать снапшот машины, а тебе говорят что нельзя, ты там рядом с машиной громко не чихай, а то система не переживёт.
	Ответить | Правка | К родителю #353 | Наверх | Cообщить модератору

	389. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (389), 04-Апр-25, 20:15
	> Разработчики на Rust почему-то хотят не что-то новое создавать на этом языке, а именно переписать старое Лгуны такие лгуны - сами что-то нелепое придумывают и озвучивают, а потом кидаются с этим бороться ... Во-первых, если и переписывают старое, то это из-за того, что старое достало своими проблемами с уязвимостями. Одни и те же типы ошибок, ничего не меняется десятилетиями. И иногда старое переписывают те же, кто изначальный продукт писАл. Наверное неспроста. А если "переписывают много" -  значит гуана накопилось много. Во-вторых. На си/плюсах, конечно же, никто не "переписывает старое". То-то почтовых серверов у нас только одна штука на все времена, сендмейл, верно? В-третьих. Адекватные разработчики, настрадавшиеся от ваших "Великих Йезыков", как раз _новое_ желают писать на расте, а старое уже стараются не трогать. Эти выводы прям открытым текстом озвучили разработчики андроида - новые системные нативные компоненты писать на расте, старое (и очень старое) си/плюсовое ерьмо - не трогать (там уже основные ошибки за десятилетия выгребли). > Не разбираюсь в качестве языка, однако "... однако мнение имею!" Вот-вот! Проходите лесом, дальше.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	461. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 23:00
	> Не разбираюсь в качестве языка, однако, что меня отталкивает в rust - это то, с какой маниакальной настойчивостью, буквально насильно, пытаются его "популяризировать". У вас проблемы с логическим мышлением. Популяризация не подразумевает никакого насилия. Другими словами, вы или проникаетесь доведенной до вас информацией и пробуете писать на новом языке программирования, или не проникаетесь, и продолжаете на том, на котором  привыкли. > Нет такого, как с Go(из новых языков), когда разработчики решают: "О, прикольный язык, напишу пожалуй свою утилиту/программу на нём." Есть и полно. Зайдите на crates.io или тот же github.com и убедитесь в этом собственноручно. > Разработчики на Rust почему-то хотят не что-то новое создавать на этом языке, а именно переписать старое. Хотят и создают. Но и переписывают тоже. Если какая-то программа восстребована - почему бы и не переписать её на более современный язык, код на котором подвержен меньшему количеству ошибок?
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

221. Скрыто модератором	+4 +/–
Сообщение от Аноним (-), 04-Апр-25, 13:16
По поводу Стандартизации языка надо ставить точку, поскольку вы не понимаете очевидных вещей. Если Rust стандартизировать на ISO, то растаманам придётся отказаться от торговой марки "Rust programming language". Растаманы на это не пойдут, им это тупо не нужно. ISO это международная организация, все её стандарты достояние человечества. ISO и торговая марка, несовместимые вещи. Когда сишку стандартизировали в 1990 году (ISO90) она стала международным явлением. Она уже не была собственностью AT&T.
Ответить | Правка | Наверх | Cообщить модератору

	356. Скрыто модератором	+/–
	Сообщение от Аноним (140), 04-Апр-25, 18:45
	>>> все её стандарты достояние человечества <<< Такие себе достояния, ибо чтобы их получить, тебе нужно забашлять бабло!
	Ответить | Правка | Наверх | Cообщить модератору

	357. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 18:50
	> ISO это международная организация, все её стандарты достояние человечества. Подскажите, пожалуйста, откуда можно загрузить последний стандарт языка Си?
	Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

264. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от YetAnotherOnanym (ok), 04-Апр-25, 14:47
> Подготовка официальной спецификации языка Rust То есть, вместо набившего оскомину > В разряд стабильных переведена новая порция API мы, наконец, прочтём > В разряд стабильных переведена последняя оставшаяся порция API ?
Ответить | Правка | Наверх | Cообщить модератору

	268. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 14:54
	Неа. Т.к спецификация может меняться. Не зря в С++ каждые 3 года выпускают новый стандарт. Особенно весело это будет в следующем или скореe через стандарт. А пока можно жевать попкорн и наслаждаться TEH DRAMA с внедрением Safe C++.
	Ответить | Правка | Наверх | Cообщить модератору

271. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от Аноним (271), 04-Апр-25, 14:55
Оказывается, что Максим Чирков не в курсе, что СШАшные корпы двигают Rust (как и государство), он думает, что это теория заговора, как он написал на форуме, поэтому удаление таких комментариев обоснованно. Хотя, они его уже давно официально ну просто рекламируют, прежде всего потому что он им выгодней С/С++ по деньгам, разработке, поддержке, о чём тоже есть информация в интернете. О том, что они двигают Раст, наверное уже только ленивый не сказал, кроме того, они это и не скрывали.
Ответить | Правка | Наверх | Cообщить модератору

	273. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 14:58
	> Хотя, они его уже давно официально ну просто рекламируют, прежде всего потому что он им выгодней С/С++ по деньгам, разработке, поддержке, о чём тоже есть информация в интернете. Погоди. Что значит "выгодней"? Если речь о "учимся легче, пишем быстрее и делаем меньше багов, экономим время программистов и тестеров" - то он выгоден всем, включая СПО. Я бы даже сказал особенно СПО, тк у корпов бабло можно грести лопатой, а свободный софт обычно в ресурсах ограничен.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–2 +/–
	Сообщение от Facemaker (?), 04-Апр-25, 17:33
	>Если речь о "учимся легче, пишем быстрее и делаем меньше багов, экономим время программистов и тестеров" - то он выгоден всем, включая СПО. Однозначно. Недаром почти любой новый опенсурсный проект, связанный с финансами (то есть с повышенной ответственностью), в блокчейне и не только, сейчас сразу и не задумываясь начинают на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (164), 04-Апр-25, 15:08
	>СШАшные корпы двигают Rust (как и государство), он думает, что это теория заговора В США едят с помощью вилок и едят хлеб. Вот интересно, борцуны давно перешли на плочки и рис?
	Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

	290. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 15:26
	>>СШАшные корпы двигают Rust (как и государство), он думает, что это теория заговора > В США едят с помощью вилок и едят хлеб. Вот интересно, борцуны давно перешли на плочки и рис? К сожалению Platinum спонсор rust foundation - это Huawei. Мегакорпа на минуточку. Значит палочки и рис уже заняты. Как и пельмени. Так что придется посконные щи лаптем хлебать.
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+1 +/–
	Сообщение от Аноним (88), 04-Апр-25, 15:14
	Насильно мил не будешь, мне ихний раст нафиг не сдался. Пускай двигают на здоровье. Видно же чьи уши там торчат. Вон флаттер подвигали уже. Для корпов подобные эксперименты - пустяк. Потом ещё раз перепишут) Здешние пиарщики не дадут соврать - платят хорошо.
	Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

333. Скрыто модератором	+2 +/–
Сообщение от Нуину (?), 04-Апр-25, 17:33
Коротко про раст: 1) Популистский и надоедливый маняпиар изо всех щелей, который почему-то рассчитан на домохозяек, а не на специалистов. (бОльшая часть растосообщества действующие веб разрабы, что уже о многом говорит) 2) Шизоидные менеджеры, которые слишком явно обслуживают интересы корпораций и придерживаются линии партии. 3) Раст - это политическая организация, а не язык программирования. Сам факт того, что на странице с описанием обновлений тебе предлагают поддержать НУЖНЫЕ движения в другой стране(например, Иране) уже о много говорит. Также лоббирование всяких КОКов, запрет "токсичных" констант и прочая неолиберальная СЖВ-шиза очень отталкивает. 4) Ужасная культура разработки, которая перешла изкультуры веб разработки. Даже для самых маленьких проектов используют leftpad.rs, которые рекурсивно тянут за собой ещё десятки зависимостей и по итогу для маленькой программы, которая выводит аналог "Hello, World" придётся скачать мегабайты и сотни тысяч(буквально) кода зависимостей. Это очень смешно слышать в контексте со словом "безопасность". Просто скачайте небольшой проект и напишите cargo tree, посмотрите количество зависимостей и попробуйте угадать в какой из них автор может закинуть вам говняк. 5) Не очень понятна ниша языка. Для серьёзных числодробилок и сырой работы с памятью все равно придётся переходить в не безопасный режим. Не легче тогда сразу писать ядро вычислений на не безопасном языке, а потом использовать языки со сборкой мусора и вообще забыть о проблемах с памятью? Да, я знаю, что есть волшебные обертки, которыми можно огородить опасные участки кода, но опять же это не даёт никаких гарантий и в случае ЧП программа просто упадёт, либо продолжит исполнение с некорректными данными. 6) Отвратная работа с динамической линковкой 7) Огромные бинарники даже после релиз мода, которые приходится strip-ать(Недавно сравнивал две аналогичные по функционалу программы, одна написана на СИ(одним файлом, лол), а другая на расте. Получилось 40Кб и 1.4МБ. Думаю, сами поймёте, что и где). 8) Долгая компиляция и ужасное "раздувание" папки с проектом, после сборки. Из проекта с весом папки 10 мб после сборки можно получить все 1.5-2.5 гб. 8) Абсолютно раковое и фанатичное сообщество(напоминаю, что большая часть сообщества выходцы из веба и скриптухи) Итог: если рассматривать раст как язык, то может быть он и заслуживает внимания(но опять же его плюсы не окупают затраты на переход), но вот все, что крутится вокруг языка - просто ужасно. Именно это окружение и отпугивает.
Ответить | Правка | Наверх | Cообщить модератору

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

	374. Скрыто модератором	+2 +/–
	Сообщение от Нуину (?), 04-Апр-25, 19:35
	>> Коротко про раст: > ps я такой текст уже видел, от того что ты будешь копипастить > его в каждую тему мир не изменится) А почему в каждой новости раста копипастится мантра про безопасность? Это другое?
	Ответить | Правка | Наверх | Cообщить модератору

	378. Скрыто модератором	+1 +/–
	Сообщение от Нуину (?), 04-Апр-25, 19:41
	>> Коротко про раст: > И это было коротко? > Как хорошо, что ты не решил писать "подробно" Это коротко, да. Для подробного изложения у местных фанатов раста не хватит усидчивости прочитать, перегорит 5-ая точка и самое главное -- потребует разбираться в теме.
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

	381. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 19:48
	> Это коротко, да. Для подробного изложения Там тоже будет забористый бред про политические организации? Или ты выйдешь на новый уровень бредовости?
	Ответить | Правка | Наверх | Cообщить модератору

	359. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 18:58
	> Именно это окружение и отпугивает. местные иксперты настолько напуганы, что обсираются в каждой новости про раст))
	Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

	361. Скрыто модератором	+/–
	Сообщение от нах. (-), 04-Апр-25, 19:00
	>> Именно это окружение и отпугивает. > местные иксперты настолько напуганы, что обсираются в каждой новости про раст)) И не говори. Что поделаешь, поколение снежинок выросло. Вот раньше программеры были готовы осваивать что-то новое, а теперь пуk-cpеньк.
	Ответить | Правка | Наверх | Cообщить модератору

	375. Скрыто модератором	+3 +/–
	Сообщение от Нуину (?), 04-Апр-25, 19:37
	>> Именно это окружение и отпугивает. > местные иксперты настолько напуганы, что обсираются в каждой новости про раст)) Местные иксперты делают тоже самое в каждой новости про си. Это другое?
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	387. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 04-Апр-25, 20:09
	>> местные иксперты настолько напуганы, что обсираются в каждой новости про раст)) > Местные иксперты делают тоже самое в каждой новости про си. Это другое? Разве? Обычно новости про СИ заключаются в том, что СИшник где-то обделался. Так что испуга я не заметил, народ скорее приходит поржать с очередного "ехал сишник через буфер и уехал в ...."
	Ответить | Правка | Наверх | Cообщить модератору

459. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
Сообщение от Аноним (459), 05-Апр-25, 22:37
кто осилил его собрать из сырцов, на локальной машине, без интернета, есть такие?
Ответить | Правка | Наверх | Cообщить модератору

	463. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Прохожий (??), 05-Апр-25, 23:14
	> кто осилил его собрать из сырцов, на локальной машине, без интернета, есть > такие? Но зачем биться головой об стену, если её можно обойти? Нет, ну разве что вы удовольствие от процесса получаете.
	Ответить | Правка | Наверх | Cообщить модератору

	466. "Выпуск Rust 1.86. Подготовка официальной спецификации языка ..."	+/–
	Сообщение от Аноним (459), 05-Апр-25, 23:55
	>Но зачем биться головой об стену удивительный язык, для сборки которого предлагается одевать трусы через голову, то бишь вместо configure make make install, преждагается запускать какие то скрипты, лезущие в интернет и скачивающие фиг знает что, например архивы прошлых версий раста и каиро, а затем всякую хрень в директорию vendor, вот нахрена спрашивается, если сорцы уже скачанные лежат, зачемто накостылен bootstrap.py с неотключаемым скачиванием этого добра, несмотря на то, само добро заранее лежит на диске, совершенно не понятная логика сборки, я глянул на рецепты сборки в LFS, арче и алпине, ощущение что разработчики специально глумились, над теми, кто опакечивать их творение будет, на счёт обойти: я не хочу в сборочныз чрутах давать выход в интернет всяким левым скриптам, неизвестно  что скачивающим и неизвестно что запускающим, я многого хочу?
	Ответить | Правка | Наверх | Cообщить модератору

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

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