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

"Представлены принципы дизайна компилятора Nimony для будущего Nim 3.0"	+/–
Сообщение от opennews (ok), 03-Май-25, 22:43
В процессе разработки языка программирования Nim 3.0 развивается новый компилятор  Nimony, основополагающим принципом проектирования которого является достижение предсказуемости времени выполнения в худшем случае (Worst Case Execution Time, WCET). Это требование продиктовано ориентацией на системы жёсткого реального времени, где недетерминированное поведение недопустимо. Как следствие, архитектура Nimony исключает использование JIT-компиляторов и сборщиков мусора с трассировкой (tracing garbage collectors), поскольку их операции могут вносить непредсказуемые задержки... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63182
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Представлены принципы дизайна компилятора Nimony для будущег..."	–6 +/–
Сообщение от th3m3 (ok), 03-Май-25, 22:43
Когда ругали Rust, часто ставили в пример Nim. И что на Nim сегодня написано, что все пользуются? Rust уже в ядро Linux даже залез.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Представлены принципы дизайна компилятора Nimony для будущег..."	+8 +/–
	Сообщение от Нуину (?), 03-Май-25, 22:48
	Если бы в brainfck столько рекламы ввалили... хайп - не показатель.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Представлены принципы дизайна компилятора Nimony для будущег..."	+3 +/–
	Сообщение от Аноним (-), 04-Май-25, 12:15
	> Если бы в brainfck столько рекламы ввалили... хайп - не показатель. Rust и C++ отлично рубятся за звание Brainfuck 2.0. А сабж попробует зарубиться за звание Brainfuck 3.0 потом. Ишь ты, со всеми этими наворотами и кучей вариантов написания и субдиалектов они в реалтайм хотят? Наверное, чтобы посмотреть что бывает если заняться подобной фигней в реалтайме? Правильно - ничего хорошего. Много новых багов, глюков и факапов на ровном месте. Говорили людям - KISS рулит. Но не, проклятие оверинженерии покусало некоторые мозги.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от BeLord (ok), 05-Май-25, 19:19
	Ну различать творчество и решение задач, а в современном мире эти понятия попутали. Инженер решает прикладную задачу, под эту задачу он делает/использует инструмент, для другой задачи этот инструмент может не подходить, значит ли это что инструмент плохой - нет, а вот инженер, который инструмент использует не по назначению, обычно, так себе специалист.
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Представлены принципы дизайна компилятора Nimony для будущег..."	–2 +/–
	Сообщение от Нуину (?), 03-Май-25, 22:49
	> И что на Nim сегодня написано, что все пользуются? А что на раст напиано, что все пользуются?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	5. Скрыто модератором	+/–
	Сообщение от Аноним (5), 03-Май-25, 22:52
	windows
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Представлены принципы дизайна компилятора Nimony для будущег..."	–5 +/–
	Сообщение от Прохожий (??), 04-Май-25, 06:24
	Уже много раз об этом писали, чуть ли не в каждой теме про этот язык. Но каждый раз находятся нуинушники и bottl-ы, которым нравится задавать одни и те же вопросы. Ну и ну! Часть Windows. Часть Android. Proxy от Cloudflare (Pigora, кажется).  Вот этим пользуются если и не все, то очень-очень многие, хотя они об этом могут и не знать. По мелочам: редактор Zed, утилита ripgrep, всякие веб-фреймворки (одни из самых быстрых в мире, если не самые быстрые). Ну и одна из подсистем ядра Линукс (хотя пока и необязательная).
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	44. "Представлены принципы дизайна компилятора Nimony для будущег..."	+4 +/–
	Сообщение от Имя (?), 04-Май-25, 07:02
	Я то думаю, чего это окна стали через одно место работать в последний год, так туда растом нагадили
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Прохожий (??), 04-Май-25, 07:11
	>чего это окна стали через одно место работать в последний год Подробностей, конечно, не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (70), 04-Май-25, 13:43
	И уязвимости в винде никуда не делись :)
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	50. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (50), 04-Май-25, 08:27
	> Часть Windows. Часть Android. Какая часть?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	71. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 14:07
	У винды - ядро переходит. Смотри презу руссиновича, где он рассказывает про перевод критических систем на раст
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 22:50
	> У винды - ядро переходит. > Смотри презу руссиновича, где он рассказывает про перевод критических систем на раст Можете ссылку дать?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 23:38
	Собственно первая ссылка по запросу "Russinovich Rust video" https://m.youtube.com/watch?v=1VgptLwP588
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Представлены принципы дизайна компилятора Nimony для будущег..."	+2 +/–
	Сообщение от Смузихлеб забывший пароль (?), 04-Май-25, 10:11
	> По мелочам: редактор Zed, утилита ripgrep, всякие веб-фреймворки >> А что на раст напиано, что все пользуются? >> все пользуются?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	112. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (112), 05-Май-25, 05:00
	Первую часть коммента (про винду и андроид), вы, естественно, проигнорировали. Удобно, чо.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 22:45
	> По мелочам: редактор Zed, утилита ripgrep, всякие веб-фреймворки Zed - сырое уг, ripgrep - цветастая замена grep, всякие веб-фреймворки - простите, но повесить обработчик на запрос можно в любом языке нормальном.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	67. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от ASRSim (ok), 04-Май-25, 12:18
	Ну я использую firefox, каждый день и иногда rustdesk. Думаю, что ещё очень дофига людей, использующих программы с растом.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	94. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 23:06
	> Ну я использую firefox, каждый день и иногда rustdesk. Думаю, что ещё > очень дофига людей, использующих программы с растом. firefox куда не шло, но там раста несравнимо мало по отношению к с++ и жс. Так что, нет.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 04-Май-25, 19:54
	Компилятор раста, внезапно. А вообще, ненавистникам раста давным давно пора запомнить, что софт на расте существует. Тот же Alacritty, ripgrep, или Cosmic DE. Так что как бы вам того не хотелось, но на расте софт внезапно пишется, во всё большем количестве.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	88. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 22:38
	> Компилятор раста, внезапно. А вообще, ненавистникам раста давным давно пора запомнить, > что софт на расте существует. Тот же Alacritty, ripgrep, или Cosmic > DE. Так что как бы вам того не хотелось, но на > расте софт внезапно пишется, во всё большем количестве. Так, а теперь выдохни и вернись, перечитай оригинальный вопрос. Перечитай еще раз. Подумай и заметь, что там есть важное замечание "все пользуются". Ты же привел в пример маргинальщину какую-то. > Компилятор раста, внезапно. А компилятор ocaml на ocaml, а компилятор sbcl на cl, а компилятор chezscheme на chez... ну ты понял.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 22:39
	>> Компилятор раста, внезапно. Ну и nim компилятор тоже на nim
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 00:19
	>Так, а теперь выдохни и вернись, перечитай оригинальный вопрос. Перечитай еще раз. Подумай и заметь, что там есть важное замечание "все пользуются" Понятие "все" - очень растяжимое. Какой-нибудь пенсионер, вздыхающий о том, что раньше дети во дворе бегали, а не за этими компьютерами сидели, не пользуется вообще ничем, ни на расте, ни на си. Пенсию получает в банке, в магазине платит наличкой. >Ты же привел в пример маргинальщину какую-то У как у ненавистников раста подогорает. Когда приводишь им в пример firefox, то они говорят - не считается, там вон сколько кода на крестах. Приводишь им в пример проект целиком на расте - не считается, этим никто не пользуется. А всё по чему? Стоит им признать, что на расте пишут, как у них тут же аргумент отвалится. И так, аргумент за аргументом, и останутся они ни с чем. И что самое главное, ненавистники раста это прекрасно понимают, что аргументов у них нет, и единственное, что они могут делать - отрицать реальность.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	124. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 11:16
	> Пенсию получает в банке, в магазине платит наличкой. Все верно. Получаеся, что нельзя утверждать, что все платят только безналом. Но и не только пенсионеры, многие платят. > У как у ненавистников раста подогорает. Когда приводишь им в пример firefox, то они говорят - не считается, там вон сколько кода на крестах. Приводишь им в пример проект целиком на расте - не считается, этим никто не пользуется. Ну потому что это истина. Ты еще скажи, что ядро линукса на расте, потому что там где-то сбоку 100 строк на нем. И ненависти тут никакой нет. Не нужно выдавать желаемое за действительное.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (86), 05-Май-25, 14:10
	>Получаеся, что нельзя утверждать, что все платят только безналом А где вы такое утверждение откапали? Сколько можно сражаться с соломенными чучелами? >Ну потому что это истина Это не истина, это ложь. Как только видим первую же строку на расте, это автоматически становится ложью. Вы же не потрудились указать количество строк? >потому что там где-то сбоку 100 строк на нем Ваше утверждение про всего 100 строк нуждается в доказательствах. Потому, что будь там 101 строка - вы уже станете лжецом. И с учётом того, что на расте активно пишут, количество строк продолжает расти, поскольку после нового коммита их количество увеличится. Один из примеров https://www.opennet.me/opennews/art.shtml?num=61794 >Bcachefs-tools недавно был переписан на языке Rust и требует использования конкретных версий компонентов Rust, которые не соответствуют версиям, поставляемым в Debian То есть на расте настолько не пишут, что аж целая bcachefs-tools каким-то образом оказалась на расте. Интересно, как же так? >Не нужно выдавать желаемое за действительное. Так это вас в первую очередь и касается. Вы готовы отрицать наличие rust-а в любом проекте, даже когда его перепишут на все 100%. Вот ещё один проект, который по вашему не написан на rust https://www.opennet.me/opennews/art.shtml?num=62811 Вон смотрите, в репозитории аж 20% кода на shell, и 5.8% на python, так что нисчитаеца!!
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Представлены принципы дизайна компилятора Nimony для будущег..."	–2 +/–
	Сообщение от Аноним (86), 05-Май-25, 00:25
	>А компилятор ocaml на ocaml Очень хорошо, что вы про Ocaml вспомнили, так как до раскрутки компилятора rust, он был написан на Ocaml. Подобные примеры очень хорошо подходят, чтобы развенчивать мифы, о том, что на каком-то языке ничего не написано
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	115. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (115), 05-Май-25, 06:22
	Скоро компилятор Раста перепишут на Си, и тогда он сам в себя схлопнется.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	8. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (8), 03-Май-25, 23:14
	Пока в Вилларибо пишут на Си, в Виллабаджо написали на Расте и уже готовятся переписывать под новую порцию стабилизированных возможностей в рамках очередной акции во "вкусно и раст"
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	24. "Представлены принципы дизайна компилятора Nimony для будущег..."	+2 +/–
	Сообщение от Аноним (24), 04-Май-25, 01:21
	Пока в Вилларибо пишут на Си, в Виллабаджо переписывают на Расте. "вкусно и коричнево", т.е. ржаво ;)
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (60), 04-Май-25, 10:44
	> переписывают на Расте. "вкусно и коричнево" Причем, что удивительно и крайне нетипично, в этом случае коричневое (внезапно) - это не г..но, а таки наконец-то шоколад!
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (24), 04-Май-25, 14:54
	"Вот и я думаю, Василий Иванович, откуда в ж взяться шоколаду?"
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от OpenEcho (?), 04-Май-25, 18:59
	К теме https://www.youtube.com/shorts/ch6DmtXsc_g
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	27. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (27), 04-Май-25, 01:27
	Что первое что второе - лютая дичь на корме у грантодателей. В реальных проектах никто не использует кроме пары хипсторов.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	38. "Представлены принципы дизайна компилятора Nimony для будущег..."	–4 +/–
	Сообщение от Прохожий (??), 04-Май-25, 06:27
	>В реальных проектах никто не использует кроме пары хипсторов А парни из Микрософт, Гугл, Клаудфлэр, Амазон, Дропбокс, Дискорд об этом знают?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Сталин (?), 04-Май-25, 07:49
	«А парни из Микрософта, Гугла, Клаудфлэра, Амазона, Дропбокса, Дискорда об этом знают?» Совсем уже русский язык забыли со своим Растом.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (-), 04-Май-25, 12:18
	> Совсем уже русский язык забыли со своим Растом. На русском языке программируют разве что 1Сники. И это даже хуже чем программирование на сабже. Сильно хуже.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от _ (??), 04-Май-25, 18:53
	DSL как DSL... Но воётивойти-шнеГам откуда знать про эти непонятные 3 буквы, оне только про другие 3 в курсе :)
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от blkkid (?), 05-Май-25, 02:57
	знаете, DSLом оно было лет 30 назад, может быть сейчас это просто изуродованный паскаль на русском от людей, которые не знают и не умеют делать хорошие языки общего пользования
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Смузихлеб забывший пароль (?), 04-Май-25, 10:12
	похоже что знают
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	30. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от keydon (ok), 04-Май-25, 01:39
	Настолько залез что пришлось его заталкивать, но и при этом его оттуда чуть не выкинули) Ну всё, мода прошла, теперь nim, а растомны не у дел. Всё как вы любите: король мертв да здравствует новый король. Об этом я еще 5 лет назад писал.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	39. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Прохожий (??), 04-Май-25, 06:33
	>Настолько залез что пришлось его заталкивать, но и при этом его оттуда чуть не выкинули Диды копротивляются. Это ведь сложно выучить ещё один ЯП. Но спонсоры (а их кода порядка 80 с лишним процентов в ядре) это не понимают. Поэтому приходится силой насаждать добро, увы.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от _ (??), 04-Май-25, 18:55
	В линуксе юзерленд уже убили. Добьют ядро и наступит то чего спонсоры и спонсировали :(
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (113), 05-Май-25, 06:14
	А нахрена учить еще один? Чтобы что? Вы дибо раст в ядро введите, либо сишку уберите. Два языка все только усложнят. Так нравится раст, ну так пепепишите на нем все ядро, какие проблемы. Сложно? А я думал вы хипстеры все мегаумные.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	120. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 10:42
	>Вы дибо раст в ядро введите, либо сишку уберите. Задача убрать из ядра код на си - явно не на пять минут. Даже если заменить си на кресты/паскаль. >Сложно? Не сложно, а долго. Или вы из тех людей, которые синусит не будут лечить, до тех пор, пока не изобретут лекарство от рака?
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Представлены принципы дизайна компилятора Nimony для будущег..."	+4 +/–
	Сообщение от Bottle (?), 04-Май-25, 03:00
	На "мёртвом" Дельфи написана FL Studio, которой пользуются тысячи людей и десятки вполне себе известных музыкантов (например, Toby Fox & Deadmaus). На "живом" и "процветающем" Rust в планах - переписать очередную софтину и не закончить этот процесс никогда. За двадцать лет великолепного развития Раста ничего толкового не было на нём написано. Даже ноунеймовый D хотя бы использовался Remedy в их играх, а ещё такая же судьба была у Haxe (Northgard как пример).
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	40. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Прохожий (??), 04-Май-25, 06:36
	>На "живом" и "процветающем" Rust Уже написаны части Андроида, Windows, proxy Cloudflare, Discord, Dropbox и куча других продуктов. Но некоторые продолжают не замечать слона, зарывшись головою в песок, как тот страус.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (53), 04-Май-25, 08:59
	>>Уже написаны части Андроида Windows, proxy Cloudflare, Discord, Dropbox и куча других продуктов. Не надоело постить это ахинею? Выкачай исходники андройда https://android.googlesource.com/ и посмотри сколько там твоего хруста, посмотришь подходи мы объясним, чем отличаются завывания "мы будем/планируем/etc использовать хруст", от реального "мы используем раст". И везде тоже самое везде - хайпа много, а реального использования с гулькин нос.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (61), 04-Май-25, 11:13
	Укажите на реальный софт, полностью написанный на ржавом, а не имеющий куски оного.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	122. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от sdf1786 (?), 05-Май-25, 10:54
	В одной компании, решили написать микросервис на расте. Уже 3 года стараются. Не сказать что в самом начале, но к проду не готовы.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от User (??), 04-Май-25, 07:34
	На аппликушечном фреймворка стяпляпали прикладную программу - А на языке системного программирования - не стяпляпали, системное программирование не нужно!
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

4. "Представлены принципы дизайна компилятора Nimony для будущег..."	+3 +/–
Сообщение от Аноним (5), 03-Май-25, 22:51
> Для документации Nimony предусмотрен сайт, полностью сгенерированный ИИ и проверенный автором Nim на достоверность. Спасибо, но нет. "Достоверности" недостаточно
Ответить | Правка | Наверх | Cообщить модератору

	7. "Представлены принципы дизайна компилятора Nimony для будущег..."	+2 +/–
	Сообщение от Аноним (7), 03-Май-25, 23:04
	Арак на официальном форуме сам писал что увлекается нейронками при написании кода. Не знаю как это оценивать.
	Ответить | Правка | Наверх | Cообщить модератору

	12. Скрыто модератором	+/–
	Сообщение от Аноним (-), 03-Май-25, 23:32
	А как это ещё оценить? Человечество движется в ад. Я не думаю что из этого что-то хорошее получится.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
Сообщение от Аноним (6), 03-Май-25, 22:59
> интеграции состояния ошибки непосредственно в сам объект данных Если компилятор не будет валидировать, что разраб проверил наличие ошибки, то это точно хуже растовых sum types. Возвращать NaN как признак ошибки -- бред, ибо NaN -- это обычное число с точки зрения системы типов. Непроверенный NaN просто просочится далее и закрашит приложение на позднем этапе в самом неожиданном месте.
Ответить | Правка | Наверх | Cообщить модератору

	15. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 03-Май-25, 23:37
	NaN означает not a number. Менеджмент состояний говорит какбы о её наличии. И это тоже некоторый результат. >> разраб ну-ну
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 14:16
	not a number, but float Как был float, так и остался. То что одно из значений обрабатываемого типа выделено под ошибку – косяк архитектуры. Индустрия прошла долгий путь развития обработки ошибок и возвращаться в дремучие времена "возвращаем число, в котором одно значение означает ошибку, а остальные – результат исполнения", для современного языка выглядит дико.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 00:23
	>NaN означает not a number Это такой же артефакт развития компьютеров, как и nullptr, ровно с теми же свойствами. Кроме того, NaN может быть только в числах с плавающей запятой, в целочисленных переменных ему не место
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	133. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (133), 05-Май-25, 13:22
	>Возвращать NaN как признак ошибки -- бред, ибо NaN -- это обычное число с точки зрения системы типов. Конечно! Надо -1 возвращать, как в сишке.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

9. "Представлены принципы дизайна компилятора Nimony для будущег..."	+3 +/–
Сообщение от Аноним (-), 03-Май-25, 23:14
Не читал весь этот огромный текст. Просто ответьте коротко. Конпилятору всё так же нужен весь набор gcc и сишные либы? Или он уже самостоятелен как go?
Ответить | Правка | Наверх | Cообщить модератору

10. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от kravich (ok), 03-Май-25, 23:25
Крч, новый Perl 6
Ответить | Правка | Наверх | Cообщить модератору

	29. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (24), 04-Май-25, 01:34
	Хм, Raku, Nimony...Да, в этом что-то есть.
	Ответить | Правка | Наверх | Cообщить модератору

11. "Представлены принципы дизайна компилятора Nimony для будущег..."	+2 +/–
Сообщение от Аноним (11), 03-Май-25, 23:32
В общем брюки превращаются ... в C++.
Ответить | Правка | Наверх | Cообщить модератору

	48. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от User (??), 04-Май-25, 07:37
	Не. Без комитета по управлению развитием стандарта - с++ не получится, это все знают. Тут эээ... Скорее modern php)
	Ответить | Правка | Наверх | Cообщить модератору

13. "Представлены принципы дизайна компилятора Nimony для будущег..."	+4 +/–
Сообщение от Карлос Сношайтилис (ok), 03-Май-25, 23:34
> основополагающим принципом проектирования является достижение предсказуемости времени выполнения в худшем случае... > примитивные типы данных напрямую отображаются на машинные слова и байты соответствующей архитектуры... Подмена понятий. Отображение в памяти никак не связано со временем исполнения. Последнее является фундаментальной проблемой и не решено в принципе. > Автор Nim выражает неудовлетворённость традиционными механизмами исключений и их эмуляцией через алгебраические типы данных (sum types). > Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. То есть, вместо универсального средства, алгебраических типов, которые позволяют без проблем завернуть любой объект в контейнер с ошибкой, предлагается набор костылей для интеграции ошибки внутрь объектов? > В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) То есть для каждого объекта будет свой none, null, nil, undefined, never и т.д. Шикарно! > В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации. О, как же много там будет нюансов в реализации этого добра при асинхронной многопоточности, да ещё в RTOS! > Тем не менее, традиционный механизм исключений Nim сохраняется, но с одним важным уточнением: любая процедура, способная порождать исключение, теперь должна быть в обязательном порядке аннотирована прагмой {.raises.}. У java не получилось подробное сделать, но у автора nim, конечно, получится! > В качестве альтернативы или дополнения вводится новый перечислимый тип ErrorCode. Цель — унифицировать обработку ошибок между различными библиотеками и обеспечить возможность прямой трансляции системных ошибок ... Использование ErrorCode также позволяет обрабатывать и распространять ошибки без выделения памяти в куче, что критично для обработки ситуаций нехватки памяти (OOM). И ровно для этого отлично подходят алг. типы. У автора языка подход не прагматичный, а религиозный. > Вместо [die on OOM] предлагается вызывать переопределяемый обработчик oomHandler. Реализация по умолчанию записывает размер неудавшегося запроса в потоко-локальную переменную и позволяет выполнению продолжиться. Позволяет нормально продолжаться при нехватке памяти? Шта? Можно ещё в логи написать: "нам не хватило памяти, но мы пляшем дальше!" --- Набор идей/нововведений напоминает письмо Дяди Федора домой. Впечатление, что писали разные люди, с разными взглядами. --- update: не сразу обратил внимание на "Для документации предусмотрен сайт, сгенерированный ИИ". Это многое объясняет.
Ответить | Правка | Наверх | Cообщить модератору

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

	73. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 14:23
	> при запуске программы выделяется некоторое количество памяти под программ... Если в таком контексте – да. Но тогда выделение памяти будет происходить на этапе компиляции и не нужен будет OOM. Но здесь описывается процесс выделения памяти в рантайме. И как решение проблемы – аналог подхода с defer в go или паники в расте. Но ни о каком "нормальном продолжении программы" в этих подходах не может идти и речи – либо обрабатывать нехватка памяти и пытаться восстановить исполнение, либо программа встаёт раком. Нормально работать продолжит только ОС.
	Ответить | Правка | Наверх | Cообщить модератору

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

	28. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (24), 04-Май-25, 01:28
	>Набор идей/нововведений напоминает письмо Дяди Федора домой. Впечатление, что писали разные люди, с разными взглядами. Писал ИИ с размножением личностей.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	33. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от fuggy (ok), 04-Май-25, 03:07
	> вместо универсального средства, алгебраических типов, которые позволяют без проблем завернуть любой объект в контейнер с ошибкой Тут особый путь. > использование NaN для чисел с плавающей запятой, или low(int) Тоже не понимаю. Так а что если у меня используются значения NaN и low(int) как обычные значения. > У java не получилось подробное сделать Понимаю что основным способом предполагается "концепция интеграции состояния ошибки непосредственно в сам объект". А raises будет что-то вроде unsafe, которую в обычным коде не рекомендуется использовать. > Позволяет нормально продолжаться при нехватке памяти А что мешает? Не выделять новой памяти, значит не порождать новых объектов и всё. Под строчку с логом выделить память заранее, и да она будет висеть в памяти всегда даже если не нужна.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	43. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Прохожий (??), 04-Май-25, 06:55
	>Так а что если у меня используются значения NaN и low(int) как обычные значения. NaN использовать в качестве обычного значения несколько странно, потому что расшифровывается оно, как not a number. А вот low(int) - да с ним могут быть двусмысленности.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 13:26
	> NaN использовать в качестве обычного значения несколько странно, потому что расшифровывается оно, как not a number. Тем не менее, это валидное значение типа float и может быть результатом выполнения каких-либо расчетов. В школе, когда изучают пределы, учат понятию "бесконечность" – это корректный ответ для предела, хотя тоже "not a number"
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 13:30
	>> Позволяет нормально продолжаться при нехватке памяти > А что мешает? Буквально – нехватка памяти. Программа для продолжения работы нужно было ещё памяти, ей не дали. Как она будет "нормально продолжать"?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	103. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 00:32
	>Программа для продолжения работы нужно было ещё памяти, ей не дали. Как она будет "нормально продолжать"? Веб сервер должен прервать исполнение текущего запроса, и вернуть 500 код ошибки. Если выполняется какая-то транзакция в базе данных, то вызвать rollback. Если создавались временные файлы - удалить их. При завершении текущего запроса, возможно и предыдущих - освободится достаточно памяти, и программа сможет продолжить работу. Для других случаев думаю и сами поймёте, по аналогии
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Май-25, 01:15
	> Для других случаев думаю и сами поймёте, по аналогии А я и в этих случаях не вижу как ты решил проблему нормального восстановления по описанному подхожу от nim. У тебя возникает ООМ на: – формировании 500й ошибки; – построении запроса на откат транзакции; – формировании массива имён временных файлов. Как будешь "нормально продолжать"? Это во-первых. Во-вторых, ты лучше опиши, как ты будешь использовать механизм, предложенный автором nim для твоих кейсов.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 10:58
	>У тебя возникает ООМ на: Я не понимаю, с чем у вас вдруг возникли такие сложности. Уже есть программы, которые при OOM не падают молча, а пишут об этом нормально сообщение. Наверное магию какую-то используют. >– формировании массива имён временных файлов. В начале нужно добавть новое имя файла в список, а уже потом создавать этот файл. В таком случае при OOM вам не придётся дополнительно выделять память
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Май-25, 14:52
	Мы сейчас не обсуждаем общие подходы к реализации аллокаторов и обработке ошибок ООМ. В этом треде, лично я, говорю _только_ о предложении автора nim. Давай ещё раз разберём, что написано в новости. > Обработка [ООМ] в Nimony реализована с отходом от распространенной практики аварийного завершения программы. Нет такой практики. Аварийное завершение программы – это обработка ошибки выделения памяти по умолчанию, когда разработчик сам на это забил. В остальных случаях, при написании программы проверяют, что память удалось выделить и обрабатывают ситуацию нехватки. Это _всегда_ дополнительная логика, предусматривающая отдельную ветку исполнения программы. Подход к проверке зависит от языка и общепризнанных практик в этом языке: проверка кода возврата, проверка адреса памяти на null, перехват исключения, перехват паники, defer обработчик и и.д. Читаем дальше. > Вместо этого предлагается механизм, позволяющий приложению продолжить работу. О! Автор придумал что-то новое! Язык сделает что-то сам, что позволит программе выполняться дальше, без дополнительных телодвижений от разработчика. Интригует! Что же это? Читаем дальше. > Контейнеры и операции выделения памяти, которые не могут выполнить запрос, вызывают переопределяемый обработчик oomHandler. Записываем: "переопределяемый обработчик oomHandler" > Реализация по умолчанию записывает размер неудавшегося запроса в потоко-локальную переменную Записываем: "код ошибки ООМ в thread-local" > и позволяет выполнению продолжиться. Это тоже записываем. > Состояние нехватки памяти для текущего потока может быть проверено вызовом threadOutOfMem(). И это. А теперь своими словами. Мы уже обсудили, что есть два подхода при обработке ошибок ООМ – их игнорирование, в этом случае вызывается аварийный останов и специальная обработка. Что происходит в nim? При неудачной попытке выделить память, вызывается обработчик, который записывает код ошибки и возвращает управление программе. 1. Если мы игнорируем обработку ошибок с памятью, то... Что? Выполнение продолжается? Очевидно нет, это невозможно. Явно будет либо останов либо ошибка сегментирования, либо что-то ещё, как ОС решит. Однако в тексте явно написано обратное. 2. Если мы хотим контролировать процесс выделения памяти, то либо переопределяем обработчик, либо проверяем код ошибки после запроса, как это делается в других языках. В сухом остатке. Так что же _нового_ предложил автор nim?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 15:15
	>Так что же _нового_ предложил автор nim? В таком случае, мы говорим о разных вещах. Да, нового ничего не предложил, только сделал реализацию не похожей, тут вы правы
	Ответить | Правка | Наверх | Cообщить модератору

14. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Нуину (?), 03-Май-25, 23:37
А за чей счет банкет? Просто интересно. Кому сдался nim, вроде недавно 2.0 был, а тут опять все ломают.
Ответить | Правка | Наверх | Cообщить модератору

	45. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Прохожий (??), 04-Май-25, 07:05
	https://opencollective.com/nim
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (55), 04-Май-25, 09:36
	Большую часть времени это было «представление одного актёра» — транспилируемая в сишечку помесь питона и паскаля/модулы. Нишевая, навроде D или Vlang. Из курьёзов — полюбившаяся малварщикам, поскольку легко писать, производительнее питона в разы, и из коробки практически всеядный FFI и нативная совместимость с сишечкой. Ну и метапрограммирование в compile-time на том же языке. Потом на это наткнулись криптовалютчики — Ethereum Foundation и ко. Дали денях. Много. И тут-то и началась вторая весна, раскрутка, популярность и признание. Так-то язык неплохой изначально. Но грядущие всеобъемлющие преобразования оптимизма не внушают.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

18. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
Сообщение от Аноним (-), 03-Май-25, 23:56
Я не в восторге от языков программирования которые создаются явно для программ. Программа создающая программу меня откровенно пугает. Людям которые такое создают нужно безгранично доверять. И более того такие люди должны обладать отличным естественным интеллектом чтобы создать что-то хорошее.
Ответить | Правка | Наверх | Cообщить модератору

19. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Аноним (20), 03-Май-25, 23:58
> Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние Ох, какой же кайф работать с такими объектами, которые на каждом шаге выполнения могут иметь невалидное значение. > любая процедура, способная порождать исключение, теперь должна быть в обязательном порядке аннотирована прагмой {.raises.}. То есть, если у меня где-то в самом низу цепочки вызовов есть бросающая функция, то я должен всю цепочку вызовов функций маркировать {.raises.}? Очень удобно! > В качестве альтернативы или дополнения вводится новый перечислимый тип ErrorCode. Ммм, старые добрые коды ошибок без какой-либо контекстной информации, когда высокоуровневая функция возвращает тебе код "что-то пошло не так", а что именно - иди разбирайся сам во всей цепочке вызовов вплоть до системных. Каеф! *** Поражает этот Nim. Авторы с упорством баранов годами пилят накой никому не нужную сборную солянку без конкретной цели и ниши, криво переизобретая проверенные временем существующие концепции и ломая совместимость с предыдущими версиями. И ладно это был бы студенческий проект, но нет же - это все на полном серьезе.
Ответить | Правка | Наверх | Cообщить модератору

	21. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (21), 04-Май-25, 00:55
	>То есть, если у меня где-то в самом низу цепочки вызовов есть бросающая функция, то я должен всю цепочку вызовов функций маркировать {.raises.}? Очень удобно! На самом деле это действительно очень удобно, знать что происходит у тебя в коде. Не зря же большинство современных языков переползли на концепт чекед эксепшенов.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (27), 04-Май-25, 01:26
	> Не зря же большинство современных языков переползли на концепт чекед эксепшенов. Теперь ясно почему современное ПО в 99.9% кривой мусор с кучей багов
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 04-Май-25, 09:51
	Тут особенность в том что программа сама себя перепрограммирует. Это как пользовательский интерфейс для робота. Есть моменты когда ты не знаешь результата, а когда получишь, то сможешь скорректировать программу.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 00:34
	Нужно как win 9x - показывать синий экран смерти и раз в две недели требовать профилактической переустановки, тогда анониму хорошо будет. И самое главное - без раста сделать.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	74. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (20), 04-Май-25, 14:24
	> большинство современных языков переползли на концепт чекед эксепшенов. Да что ты! Назовешь хоть один, кроме Java (в которой эти checked exceptions все ненавидят)?
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	105. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 00:36
	Если в вашем языке продвинутая система типов, то монады типа Option или Result будут вам знакомы.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Май-25, 14:37
	> На самом деле это действительно очень удобно, знать что происходит у тебя в коде. Удобно, но, к сожалению, невозможно. > Не зря же большинство современных языков переползли на концепт чекед эксепшенов. Чекед не работает везде где есть. Всегда всё заканчивается антипаттерном "вот в этом месте ловим вообще все исключения" без разбора и выдаём ошибку "что-то пошло не так"
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	34. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от fuggy (ok), 04-Май-25, 03:10
	> должен всю цепочку вызовов функций маркировать А когда ты async пишешь или unsafe, тоже приходится маркировать все функции до самой последней.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	41. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Прохожий (??), 04-Май-25, 06:47
	Не приходится.
	Ответить | Правка | Наверх | Cообщить модератору

35. Скрыто модератором	+/–
Сообщение от Аноним (-), 04-Май-25, 05:28
Для системного программирования есть Си. А режим реального времени может обеспечить ядро Линукса.
Ответить | Правка | Наверх | Cообщить модератору

36. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
Сообщение от Аноним (36), 04-Май-25, 05:55
> требуется явная аннотация прагмой .cyclic Всё, сразу фейл. Ожидать правильного  аннотирования от тех же самых программистов, которые не могут посчитать размер массива с первого раза — утопическая идея. Пока компилятор не начнёт бить по пальцам линейкой прогресса в качестве кода не будет.
Ответить | Правка | Наверх | Cообщить модератору

51. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
Сообщение от Аноним (51), 04-Май-25, 08:35
Nim — хороший язык. Не вызывает болей и отторжения.
Ответить | Правка | Наверх | Cообщить модератору

	83. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от _ (??), 04-Май-25, 18:59
	Никто не юзает, вот и "не вызывает" :-)
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (84), 04-Май-25, 19:07
	За всех не говори.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 22:42
	Как там с отладкой сгенерированного кода? Только не говори, что принтами отлаживаешься)))
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 03:24
	> Только не говори, что принтами отлаживаешься Это ещё вопрос, что удобнее, в IDEшке наклепать принтов и break'ов, или мучать отладчик. Но часто отладка вообще не нужна, тем более с нейросетями и копайлотом.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 11:18
	> Но часто отладка вообще не нужна, тем более с нейросетями и копайлотом. Этот ответ даже лучше принтов, браво. Надо так и записать на главной проекта: код легкочитаем настолько, что отладка попросту не нужна (спойлер: ее как бы и так нет))))
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 11:18
	Я если что без негатива)
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (131), 05-Май-25, 12:38
	Строгая типизация с прозрачным понятным синтаксисом позволяют обнаруживать ошибки без особых проблем. Nim разработан для созидания и реализации идей, а не траты времени на ошибки. В 19 случаях из 20 достаточно сообщений компилятора.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	139. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (139), 05-Май-25, 15:28
	Язык с таким синтаксисом просто не может быть хорошим.... Может боли он и не вызывает, но читаемость ещё как ухудшает
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

59. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Смузихлеб забывший пароль (?), 04-Май-25, 10:26
Одно неясно - если пилится нечто для систем реального времени, то где хотя бы одна норм ОСРВ на Ним ? Как там с поддержкой железа, разных МК ? И, что ещё более немаловажно, обычно СРВ подразумевают, в числе прочего, прерывания. В статье о них ни слова. Что это за "ЯП для СРВ" без прерываний и без ОСРВ ? Что-то подсказывает, что, при необходимости сертификации продукта на этом, вместо результата будет здоровенный хрен и, скорее всего, даже без соли
Ответить | Правка | Наверх | Cообщить модератору

76. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Аноним (-), 04-Май-25, 14:46
> В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации. Чуваки явно недостаточно писали на C. Явно errno не успел их достать до печёнок. > Тем не менее, традиционный механизм исключений Nim сохраняется Лол, и на всяких python'ах они писали недостаточно. Когда отсутствие элемента в массиве приходится обрабатывать исключением это раздражает до безумия. > Обработка ситуаций исчерпания памяти (Out of Memory, OOM) в Nimony реализована с отходом от распространенной практики аварийного завершения программы ("die on OOM"). Вместо этого предлагается механизм, позволяющий приложению продолжить работу. Глупости. Сложности ради сложности. Если памяти не хватает, oomkiller всё равно прибъёт, заводить специальные механизмы, которые может быть успеют сработать до oomkiller'а, а может нет, пустая трата времени.
Ответить | Правка | Наверх | Cообщить модератору

	85. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 04-Май-25, 19:50
	>> Обработка ситуаций исчерпания памяти (Out of Memory, OOM) в Nimony реализована с отходом от распространенной практики аварийного завершения программы ("die on OOM"). Вместо этого предлагается механизм, позволяющий приложению продолжить работу. >Глупости. Сложности ради сложности. Если памяти не хватает, oomkiller всё равно прибъёт, заводить специальные механизмы, которые может быть успеют сработать до oomkiller'а, а может нет, пустая трата времени. Не глупость, это чуть ли не единственная здравая идея. Если ограничить размер виртуальной памяти, то гарантированно никакого oom killer-а не будет, будет ошибка, которую можно элементарно обработать в user space. Просто г0вн0к0деры настолько обленились, что обработать данную ошибку для них - непосильная задача.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 17:21
	> Если ограничить размер виртуальной памяти, то гарантированно никакого oom killer-а не будет, будет ошибка, которую можно элементарно обработать в user space. Расскажи, как это реализовать. Обычно у меня не возникает ситуаций, когда нехватка оперативной памяти — это не ошибка, на которую единственная адекватная реакция — это завершение работы. Если бы это было исключением, которое можно было бы поймать и обработать, то можно было бы улучшить сообщение об ошибке, сделав его более понятным для пользователя. Без этого часто сообщения об ошибках, связанные с нехваткой памяти, выглядят довольно запутанно. Но если бы это было так просто, то, вероятно, имело бы смысл. Проблема усугубляется тем, что в системе одновременно работает множество процессов, и оперативная память — это общий ресурс. Когда она заканчивается, это результат работы многих процессов. Какому из них стоит завершиться? Подход oom killer основан на эвристике, и, как ты знаешь, он работает. В моем случае начинают закрываться вкладки Firefox, а то, что потребляет 16-20 гигабайт, продолжает работать до конца. Этот метод позволяет вкладкам Firefox в обычных условиях функционировать без проблем, но в случае нехватки памяти он их завершает. В отличие от твоего подхода, который предполагает установку единого статического лимита на память для вкладок, из-за чего они могут падать даже тогда, когда свободной памяти предостаточно. Так как процесс может решить правильно, что делать в случае исчерпания лимита на виртуальную память. Как, не изучая глобальной по системе ситуации с памятью, он может решить надо ли ему венуть ошибку для текущей операции, упать насовсем, или увеличить себе лимит и повторить ту операцию, которая выкинула оом-ошибку.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 19:48
	>Подход oom killer основан на эвристике, и, как ты знаешь, он работает Я бы не был в этом так уверен. Ядерного OOM я ни разу не мог дождаться, даже за час, только вечный своп. >В моем случае начинают закрываться вкладки Firefox, а то, что потребляет 16-20 гигабайт, продолжает работать до конца Вот именно, что в вашем случае. OOM недетерминирован и и неотёсан, это грубая разрушительная сила. Предсказать, кого OOM убъёт в общем случае невозможно. Допустим, вы подняли несколько микробекендов, которые используют Redis. OOM скорее всего начнёт с вкладок, потом прихватит IDE, а потом заберёт Redis. Далее, если вам повезёт, то текущий процесс доработает, а если не повезёт, то дальше этот процесс полезет за чем-то в Redis и упадёт, так как Redis-а больше нет. Скорее всего этот Redis нужно будет поднимать руками, так как для разработки он был запущен руками, а не как systemd unit. А если особенно сильно не повезёт, то при падении Redis-а побъётся база данных и её нужно будет вручную удалять с диска. >Этот метод позволяет вкладкам Firefox в обычных условиях функционировать без проблем, но в случае нехватки памяти он их завершает Данный подход работает, когда задачи не важны, и есть какой-то супервизор, который будет следить за целостностью системы. Но в ситуации, когда может отвалится какой-то важный кусок, при этом молча, данный подход уже не выглядит таким привелкательным.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 21:22
	Первое, что вам следует понять, это то, что ситуации ООМ — это неизбежно системные сбои, и какую бы стратегию работы с этими сбоями вы не выбирали, это по-любому костыли. В системе, критичной к сбоям, никаких ООМ просто быть не должно. Памяти должно быть столько, сколько нужно системе. Система должна быть спроектирована так, чтобы вы могли посчитать, сколько памяти потребуется в худшем случае. А это значит, что никаких firefox'ов в системе быть не должно. Или если они есть, то они должны быть гвоздями прибиты к отображению одного специально созданного сайта, не давая никакой возможности пользователю пойти смотреть порнушку. Если же вы на такие ограничения в системе не согласны, то вам придётся постоянно ходить под дамокловым мечом ООМ, и в случае, когда ООМ случается, каким-то процессам придётся падать. Подход nim как бы предполагает, что каждый процесс будет получать ошибку выделения памяти и как-то её обрабатывать. Но фишка ведь в том, что когда память заканчивается, первым ошибку выделения памяти может получить процесс, который использует минимум памяти. Это случится, если ему не повезёт дёрнуть malloc в тот момент, когда система столкнулась с нехваткой памяти. То есть процесс, который первым узнает про ООМ, может не иметь способов снизить потребление памяти. Что хуже, он не знает нюансов происходящего, их можно узнать только исследуя, куда же вся память системы была потрачена. А без этих нюансов он не может сделать обоснованный выбор между "падать" или "повторять попытку выделить память". Если на ситуацию взглянуть теоретически, то для того, чтобы принять обоснованное решение о том, как справляться с возникшим ООМ, надо видеть всю картинку в целом. Куда потрачена память и насколько важными вещами занимается каждый из процессов, чтобы потом (в идеальной ситуации) выбрать тот, который занимается чем-то не очень важным, но использует много памяти. Или может выбрать много неважных процессов, которые потребляют немного памяти, но их много, и прибить их. При этом, если смотреть глазами процесса, то тот не знает ничего. Он не знает, насколько его работа важна для системы, он не знает, кто сколько памяти жрёт. Он мог бы, конечно, просмотреть карту памяти и узнать всё, что известно oom-killer'у, но зачем, если этим может заниматься oom-killer? > Допустим, вы подняли несколько микробекендов, которые используют Redis. OOM скорее всего начнёт с вкладок, потом прихватит IDE, а потом заберёт Redis. Далее, если вам повезёт, то текущий процесс доработае[...] Если есть возможность подобного развития ситуации, то кому-то следует докупить оперативки. Или подумать о том, чтобы либо настроить oom-killer потоньше, чтобы он какие-то процессы не трогал, или запустить эти процессы на отдельной железяке. То есть, в принципе oom-killer -- это костыль, заменяющий дополнительные планки оперативки. С одним нюансом: возможны ситуации, когда никакой оперативки не хватит, например, в случае бажной программы. В этих ситуациях oom-killer тоже может быть полезен.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 23:08
	>А без этих нюансов он не может сделать обоснованный выбор между "падать" или "повторять попытку выделить память". Есть ещё несколько вариантов. Например, можно корректно завершиться, например, удалив временные файлы. А ещё можно остановить текущую операцию. >Но фишка ведь в том, что когда память заканчивается, первым ошибку выделения памяти может получить процесс, который использует минимум памяти И это хорошо. Новый процесс сообщит о том, что работать он не может, и завершится. Никакой существующий процесс убит не будет >Он мог бы, конечно, просмотреть карту памяти и узнать всё, что известно oom-killer'у, но зачем, если этим может заниматься oom-killer? Так в этом и заключается моя претензия: oom killer не заботится ни о каких инвариантах, он просто завершает процессы. Насколько корректным останется система после его запуска - неизвестно. Может убить вкладку, а может сразу весь браузер, может сразу всю графическую сессию. https://www.linux.org.ru/forum/desktop/16229420 >То есть, в принципе oom-killer -- это костыль, заменяющий дополнительные планки оперативки Или говоря иначе, текущий userspace у линукса такой, что может работать только с избытком памяти. Нужно иметь более 10% памяти свободной, а желательно ещё больше. Вплоть до 50% свободной памяти. А всё по тому, что свободная память, она на самом деле не свободная, и при её нехватке возможны самые разные спецеффекты >или запустить эти процессы на отдельной железяке. Внезапно. Поскольку даже непривелигированный код при определённых условиях сможет создать ситуацию, когда oom killer будет убивать недоступные для непривелигированного кода процессы.
	Ответить | Правка | Наверх | Cообщить модератору

87. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Аноним (86), 04-Май-25, 20:05
>основополагающим принципом проектирования которого является достижение предсказуемости времени выполнения в худшем случае (Worst Case Execution Time, WCET). Это требование продиктовано ориентацией на системы жёсткого реального времени, где недетерминированное поведение недопустимо Это что, язык для микроконтроллеров? Если на нём будет удобно писать под микроконтроллеры, то автоматически станет неудобно писать почти всё остальное >Данный режим базируется на подсчёте ссылок с использованием атомарных операций, дополненном семантикой перемещения (move semantics) и вызовом деструкторов при уничтожении объекта, что сближает подход с практиками, принятыми в Rust и современном C++. В языке появятся афинные типы, как в rust? Так чем nim будет лучше чем rust? Или будет непрекращающийся кошмар с порчей памяти как на c++? Но зачем нужны вторые кресты, первых крестов и так слишком много >Автор Nim выражает неудовлетворённость традиционными механизмами исключений Единственное, что плохо в исключениях - отсутствие описания исключений в сигнатурах функций. Емнип в java сделано нормально >Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) для невалидных целочисленных значений Мало автору ошибки на миллиард долларов - наличие null, так теперь ещё больше ошибок будут просачиваться везде >В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации Которую крайне легко поппустить, оставив ошибку не обработанной. Спасибо Удивительно, что никто из коментаторов ничего не написал про необходимостть переписывания существующеного кода на ним, неужели все к этому привыкли?
Ответить | Правка | Наверх | Cообщить модератору

	95. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 04-Май-25, 23:10
	> Единственное, что плохо в исключениях - отсутствие описания исключений в сигнатурах функций. Емнип в java сделано нормально Если ты вызываешь функцию в своем коде, то надо руками скопипастить её исключения наверх? Точно нормально? Смысл тогда в них?
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 10:40
	>то надо руками скопипастить её исключения наверх? Я конечно давно не сталкивался с java, но что, там нужно как в голанге делать? if err != nil {     return nil, err } Или вы про ручное указание в сигнатурах? Как и ожидалось от языка без вывода типов. А ещё там нужно указывать тип для каждого аргумента у любого метода. Языки с выводом типов по Хиндли-Милнеру если не ровесники, то уж точно старше чем java. >Смысл тогда в них? Смысл в том, чтобы исключения были исключениями, а не паникой, которая высвобождает ресурсы и закрывает программу. Где ещё можно посмотреть, какие исключения код может кинуть, а какие - нет? Уж не ревьювить все библиотеки, от начала и до конца
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 11:26
	>>то надо руками скопипастить её исключения наверх? > Я конечно давно не сталкивался с java, но что, там нужно как > в голанге делать? > if err != nil { >     return nil, err > } > Или вы про ручное указание в сигнатурах? Как и ожидалось от языка > без вывода типов. А ещё там нужно указывать тип для каждого > аргумента у любого метода. Языки с выводом типов по Хиндли-Милнеру если > не ровесники, то уж точно старше чем java. Да, про указание. >>Смысл тогда в них? > Смысл в том, чтобы исключения были исключениями, а не паникой, которая высвобождает > ресурсы и закрывает программу. Где ещё можно посмотреть, какие исключения код > может кинуть, а какие - нет? Уж не ревьювить все библиотеки, > от начала и до конца Посмотреть возможные исключния в документации. Смысл в том, чтобы писать и не париться об обработке исключений, которые не хочешь обрабатывать. Перекидывать же все возможные исключения в нижележащем коде через указание в сигнатуре будет еще та морока как мне кажется.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 14:16
	>Посмотреть возможные исключния в документации Документация - для данной цели это плохо. Она не выдаёт ошибок компиляции, её могут забыть обновить, перечитывать огромный release notes для новой версии будет утомительно. >Смысл в том, чтобы писать и не париться об обработке исключений, которые не хочешь обрабатывать Ну так кто виноват в том, что в java нет мощного механизма для вывода типов? А если я строку на класс захочу поменять, это точно так же нужно её будет по всему стеку вызова менять, хотя достаточно было поменять в коде двух методов, минуя все прослойки. Будь в java вывод типов, так список исключений формировался в большинстве случаев самостоятельно.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 17:27
	> Перекидывать же все возможные исключения в нижележащем коде через указание в сигнатуре будет еще та морока как мне кажется. Добро пожаловать в мир корректной обработки ошибок. Когда возникает ошибка, в общем случае тебе надо пройтись по всему бектрейсу и решить где именно эту ошибку обрабатывать. Если ты не остановился и не подумал об этом, то скорее всего ошибка будет "обработана" не там, где следует. Как ты можешь быть уверен, что каждая твоя функция была обдумана тобой, с точки зрения какие исключения обрабатывать, а какие прокидывать вверх по стеку, и что ты не упустил ни одного типа исключения, если за тебя это не проверяет статический анализ? Я не знаю как, я уверен что никак, что ты просто кладёшь на это болт. Но если бы ты не клал, ты бы писал для каждой функции список типов исключений, который та выкидывает, чтобы статический анализатор (возможно встроенный в компилятор) проверил бы, что ни один тип исключений не упущен.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	143. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 17:33
	>> Перекидывать же все возможные исключения в нижележащем коде через указание в сигнатуре будет еще та морока как мне кажется. > что ты просто кладёшь на это болт Разумеется в этом и суть исключений: обрабатывать только то, что надо. Этим они отличаются от проверки каждого кода. Если не обработал, то вылетит на верхний уровень и завершится. В чем проблема? Залогируешь, перезапустишь. А растовщики болт не кладут, когда пишут unwrap? Или это другое? Да у тебя любое выделение памяти может вернуться с ошибкой, вот я бы хотел посмотреть как ты будет проверять, что добавление в вектор не завершилось такой ошибкой. Ты представляешь уровень бойлерплейта?
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 20:07
	>вот я бы хотел посмотреть как ты будет проверять, что добавление в вектор не завершилось такой ошибкой. Ты представляешь уровень бойлерплейта? Проблема в том, что кроме тех ошибок, которые могут возникнуть чуть ли не на кадой строке, типа переполнения или OOM, информации о других типах ошибок нет. Вот вам пример https://pkg.go.dev/os#Create >  If there is an error, it will be of type *PathError Вот мне интересно, нехватка места на диске, это тоже PathError ? А проблема с правами? А если диск примонтирован по сети, а сеть упала? >В чем проблема? Залогируешь, перезапустишь. К каждой программе должен быть приставлен специалист, который будет следить за её работой. Подход Haskell/Ocaml/Rust - скомпилировалось значит работает - не изобретён.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 20:30
	> Разумеется в этом и суть исключений: обрабатывать только то, что надо. Это не суть исключений (исключения лишь механизм). Это суть раздолбайского отношения к корректности кода. > А растовщики болт не кладут, когда пишут unwrap? Охлол, раст-то здесь причём? В расте нет исключений.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	150. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 20:39
	> Это суть раздолбайского отношения к корректности кода. Разработчики erlang'а вышли из чата.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 20:41
	> Охлол, раст-то здесь причём? В расте нет исключений. Сообщения не читай, комментарии пиши? Ну нет, зато есть обработка ошибок, которую тут продвигают. Только вот пишут все unwrap и как бы точно также забивают на ошибки, позволяя программе просто упасть. В чем разница с тем, что я не буду писать никакие unwrap и тоде позволять ей падать?
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	155. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (155), 05-Май-25, 21:33
	> Сообщения не читай, комментарии пиши? Я читаю, то на что отвечаю. Конкретно я придрался к этому твоему высказыванию: > Смысл в том, чтобы писать и не париться об обработке исключений, которые не хочешь обрабатывать. Перекидывать же все возможные исключения в нижележащем коде через указание в сигнатуре будет еще та морока как мне кажется. И я ещё раз тебе повторяю, это раздолбайское отношение к корректности программы. Исключения не для того, чтобы не париться об обработке ошибок. Они могут быть альтернативой афинным типом, более того бывают ситуации, в которых они лучше афинных типов. Иногда они удобнее программисту, а иногда ускоряют обработку ошибок: в тесном цикле, в котором каждая проверка добавляет тормозов, исключения ухудшают худший случай (когда вылетают все ошибки, которые только возможны, причём с максимальной частотой), но лучший, оптимистичный, при котором ошибок не возникает вовсе, они улучшают.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 23:56
	>> Сообщения не читай, комментарии пиши? > Я читаю, то на что отвечаю. Конкретно я придрался к этому твоему > высказыванию: >> Смысл в том, чтобы писать и не париться об обработке исключений, которые не хочешь обрабатывать. Перекидывать же все возможные исключения в нижележащем коде через указание в сигнатуре будет еще та морока как мне кажется. > И я ещё раз тебе повторяю, это раздолбайское отношение к корректности программы. > Исключения не для того, чтобы не париться об обработке ошибок. Они в том числе и чтобы не обрабатывать ошибки от каждого вызова. И принцип lets it crash вполне себе используемый. Ну не выкатываешь же ты в прод код без мониторингов и возможности рестрата при падении, если он скомпилировался лол.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 23:59
	>> Сообщения не читай, комментарии пиши? > Я читаю, то на что отвечаю. Конкретно я придрался к этому твоему > высказыванию: Ты в раст в пример ставишь, а какой смысл в бесконечных unwrap? Это тоже самое, что отказаться от обработки ошибок и перейти на исключения. Или ты пишешь матчинг на каждую ошибку? И что делаешь? Логируешь поди?))))
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	159. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (36), 05-Май-25, 22:41
	Пока что единственный язык где обработка исключений сделана хорошо — это Common Lisp. С тех пор как его стандартизировали в 1994 году, никто лучше так и не смог предложить. То, что ты рассказываешь про «ни один тип исключений не упущен» — это фантазии цветными карандашами в тетрадочке, и работает только в hello world. Не все исключения _могут_ быть обработаны, и уж тем более не все исключения _должны_ быть обработаны. Красиво упасть — один из приемлимых результатов выполнения программы.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

90. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Нуину (?), 04-Май-25, 22:41
Проблема автора языка, что видимо он до сих пор не понимает цели: какая у него целевая аудитория. Как говорится "у самурая только путь". Только вот оценят ли пользователи?
Ответить | Правка | Наверх | Cообщить модератору

	110. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Аноним (-), 05-Май-25, 03:20
	Nim один из лучших по синтаксису, не вызывает рвотного рефлекса в отличии от го, си или (упаси Господь) руста. Но не взлетел. В современном мире если продукт не взлетает сразу, то вероятность, что взлетит со временем стремится к нулю.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (116), 05-Май-25, 09:24
	Python смотрит на вас с недоумением
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 10:48
	>Nim один из лучших по синтаксису Исспользование отступов вместо операторных скобок - уже достаточный минус языка. Ничему опыт питона не учит
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	127. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Нуину (?), 05-Май-25, 11:22
	По мне к синтаксису особых претензий нет. Среди сотни новых языков, копирующих фигурные скобочки, языки вдохновляющиеся питоном, ada и модулой - прям отдушина. В целом я желаю проекту удачи.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (131), 05-Май-25, 12:30
	> Ничему опыт питона не учит То есть опыт языка, занимающего первые строчки большинства рейтингов популярности, – неправильный опыт?
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	136. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (86), 05-Май-25, 14:43
	>То есть опыт языка, занимающего первые строчки большинства рейтингов популярности, – неправильный опыт? А почему он должен быть правильным? Поскольку миллионы мух не могут ошибаться? Во-первых, есть огромный вопрос в достоверности этих списков, так как согласно другим рейтингам первое место будет всё же у js. А если учесть, что в то время, как на условном go будет писать только голангер, пхпешник будет писать на пхп, то вот каждый из них может по быстрому накидать несколько строк на js, то делить место js как и питона надо раз в десять, а то и больше. Во-вторых, эти списки сравнивают несравнимое, и в том же списке, где и python будет sql, bash, хотя это другие языки с другими задачами. Хорошо хоть html там не ставят. В-третьих, места в списке языки занимают просто по тому, что так принято. Очередной вайтишник смотрит на топ языков, и начинает учить их за компанию. Он не может сравнить его с другим языком, так как он других языков он банально не знает. А компании тоже выбирают язык либо из топа, либо того, который на хайпе, ибо они хотят максимально широкий выбор из программистов. Для того, чтобы понять, насколько python ужасен, достаточно всего лишь раз поломать программу из-за отступа. Хоть из буфера обмена вставить, хоть в любое место, обрезающие ведущие пробелы, да даже открыть в редакторе с другими отступами. Это всё равно, как если бы при копировании кода на си подобных языках, в код могли бы случайно попасть несколько скобочек, и никто заранее не знает каких. После того, как я увидел, что редактор может сам расставлять отступы, как например здесь https://try.ocamlpro.com/, я понимаю, что решение применяемое в питоне - костыль заслуживающий безусловного осуждения
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 16:19
	> Для того, чтобы понять, насколько python ужасен, достаточно всего лишь раз поломать программу из-за отступа. Хоть из буфера обмена вставить, хоть в любое место, обрезающие ведущие пробелы, да даже открыть в редакторе с другими отступами. У тебя затертые ctrl+c, потому что ты копируешь код. У меня затертые ctrl+c, потому я останавливаю бесконечные циклы. Мы разные. (с)
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (86), 05-Май-25, 19:55
	>У меня затертые ctrl+c, потому я останавливаю бесконечные циклы Просто интересно, что это нужно делать, чтобы затереть кнопки на остановке циклов? Да к томуже запущеных в терминале, ни в виде демона, ни в виде графической программы, запущенной без терминала
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
	Сообщение от Аноним (-), 05-Май-25, 20:04
	> То есть опыт языка, занимающего первые строчки большинства рейтингов популярности, – неправильный опыт? Да. Мне приходится писать на пайтоне, и в эти периоды у меня дня не проходит без того, чтобы я не получил бы рантайм ошибки из-за того, что где-то поехала идентация. Как правило это случается из-за того, что я решил блок завернуть в другой блок, или убрать внешний блок, как следствие я менял идентацию блоку, и одну из строчек пропустил. У emacs'а есть команды для изменения идентации (C-c <, C-c >), но чтобы они работали бы надо выделить блок, не промазав мимо нужной строчки ни в начале, ни в конце. Я вообще не привык с идентацией возиться. В большинстве случаев идентацией занимается emacs, от меня не требуется никаких специальных телодвижений, чтобы код был бы идентированным. В случаях же правок, которые ломают идентацию блоков, я просто нажимаю C-c C-s, файл сохраняется, триггерится внешний форматер кода, и он расставляет всё как надо. Или не как надо, если я напутал со скобочками (а это, как правило, ошибки вида "лишняя или недостающая скобочка"), но это видно по ошибкам форматера и по тому как идентация кода поехала. На работу же с пайтоном никакой слюны не хватает плеваться. Столько тупой ручной работы по добавлению/удалению пробелов, что я до сих пор понять не могу, почему пайтон ещё не выкинули на свалку истории.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	153. "Представлены принципы дизайна компилятора Nimony для будущег..."	+3 +/–
	Сообщение от Инженер на пенсии (?), 05-Май-25, 21:11
	> Столько тупой ручной работы по добавлению/удалению пробелов Бедолага, и как только раньше ПРОГРАММИСТЫ (не кодеры) писали программы без IDE и отправляли космические аппараты изучать внешний и внутренний КОСМОС?! Вам бездельникам итак предоставили райские условия, всякие Copilot, автодополнения кода и прочие удобности, а вы максимум что освоили, так это Тик-Токи в своих айфонах.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Представлены принципы дизайна компилятора Nimony для будущег..."	–2 +/–
	Сообщение от Аноним (86), 05-Май-25, 22:24
	>Бедолага, и как только раньше ПРОГРАММИСТЫ (не кодеры) писали программы без IDE Даже интересно, что же они такого написали >и отправляли космические аппараты изучать внешний и внутренний КОСМОС Я не знаю, что вас так впечатляет в слове космос, но эти программы невероятно примитивны >итак предоставили райские условия, всякие Copilot Во-первых, copilot это вещь относительно новая, и от необходимости следить за отсупами она никак не защищала большую часть истории питона. Во-вторых, эта технология требует крайне внимательного изучения кода, поскольку сгенерированный ИИ код содержит самые разные ошибки, а порой и просто не работает. В-третьих, в некоторых случаях будет быстрее самому написать код, чем добиваться его от машины. >автодополнения кода Которое откровенно слабо работает для динамически типизированных языков, типа питона >и прочие удобности Сколько удобств нужно дать человеку, чтобы он добровольно согласился на неудобства?
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (161), 05-Май-25, 22:47
	> Сколько удобств нужно дать человеку, чтобы он добровольно согласился на неудобства? Спроси тех, кто пердолит линуксы вместо уютной и удобной одиннадцадки.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Представлены принципы дизайна компилятора Nimony для будущег..."	–2 +/–
	Сообщение от Аноним (36), 05-Май-25, 22:45
	> как только раньше ПРОГРАММИСТЫ (не кодеры) писали программы без IDE Крайне медленно, при чём писали они такую примитивщину, которую сегодня в наше время заставляют писать джунов c IDE. Сесть на Луну сложно отнюдь не потому, что сложно написать код.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	162. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (161), 05-Май-25, 22:48
	> писали они такую примитивщину Пропepдел очередной малoлeтний дeгeнеpaт родившийся с айфoном в люльке. Ага.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Представлены принципы дизайна компилятора Nimony для будущег..."	+1 +/–
	Сообщение от Инженер на пенсии (?), 05-Май-25, 21:07
	> Исспользование отступов вместо операторных скобок - уже достаточный минус языка. Это однозначный и КРАЙНЕ весомый плюс. Скобки ты можешь поставить где угодно и нагородить такой огород, что сам не разберешься на следующее утро, что ты там накодил. Отступы это в первую очередь единообразие в оформлении кода, а значит залог порядка в коде.
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	156. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Май-25, 22:10
	> В современном мире если продукт не взлетает сразу, то вероятность, что взлетит > со временем стремится к нулю. В современном мире языкам нужно 10-15 лет "на взлёт". Сколько Nim?
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	157. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Аноним (-), 05-Май-25, 22:14
	в современном мире если этот язык не привнести чего-то революционного, то он не взлетит вообще никогда, потому что ниши заняты проверенными инструментами с жирными сообществами
	Ответить | Правка | Наверх | Cообщить модератору

108. "Представлены принципы дизайна компилятора Nimony для будущег..."	–1 +/–
Сообщение от Аноним (108), 05-Май-25, 02:05
Вакансии где? Я тоже писал свой язык и что дальше?
Ответить | Правка | Наверх | Cообщить модератору

	128. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
	Сообщение от Нуину (?), 05-Май-25, 11:23
	Создавай свою контору и пиши на нем.
	Ответить | Правка | Наверх | Cообщить модератору

118. "Представлены принципы дизайна компилятора Nimony для будущег..."	+/–
Сообщение от Данные в так называемом поле Name (?), 05-Май-25, 10:18
> основополагающим принципом проектирования которого является достижение предсказуемости времени выполнения в худшем случае Первая интересная фишка у этого языка. Правда то что запилить её решили в 3й версии оптимизма не внушает. Уже можно сказать что проект мертворожденный ИМХО.
Ответить | Правка | Наверх | Cообщить модератору

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

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