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

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

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

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

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

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

	8. "Представлены принципы дизайна компилятора Nimony для будущег..."	+2 +/–
	Сообщение от Аноним (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ообщить модератору

	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ообщить модератору

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

	40. "Представлены принципы дизайна компилятора Nimony для будущег..."	–2 +/–
	Сообщение от Прохожий (??), 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ообщить модератору

	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 для будущег..."	+/–
Сообщение от Аноним (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ообщить модератору

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ообщить модератору

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

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

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

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

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

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

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

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

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