The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Выпуск языка программирования Nim 2.2.8"  +/
Сообщение от opennews (??), 23-Фев-26, 22:34 
Представлен релиз языка системного программирования Nim 2.2.8. Nim – статически типизированный компилируемый язык программирования с синтаксисом, вдохновлённым Python, и возможностями метапрограммирования на уровне Lisp. Язык компилируется в C, C++ и JavaScript, обеспечивая производительность на уровне C при выразительности высокоуровневых языков.  Код проекта поставляется под лицензией MIT...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64858

Ответить | Правка | Cообщить модератору

Оглавление

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

7. Сообщение от 12yoexpert (ok), 23-Фев-26, 23:09   +/
> инстанциаций

афордабл хоть?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

10. Сообщение от вдцлсоцжтчфлыь (?), 24-Фев-26, 00:48   –4 +/
Кто-то: если ваш ним так хорош, что все игры на графах к нему сводятся по теореме Шпрага-Гранди, то почему ещё не выпустили ним 2?

тем временем ним 2:

Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от Аноним (11), 24-Фев-26, 02:51   –5 +/
С таким списком багфиксов использовать это в проде будет только хеловротщик
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

12. Сообщение от Анонимemail (12), 24-Фев-26, 07:02   –2 +/
Зачем он нужен? Какие проблемы он решает?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #25, #29

13. Сообщение от Аноним (14), 24-Фев-26, 07:47   +1 +/
Исчерпывающие ответы на Ваши вопросы содержатся в следующем фрагменте новости:
> позиционируется как системный язык, подходящий для разработки от встраиваемых систем до веб-серверов, с акцентом на эффективность, безопасность памяти и удобство разработки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15, #26

14. Сообщение от Аноним (14), 24-Фев-26, 07:49   +1 +/
Если действовать с такой же настойчивостью, как в отношении офтопика, баги не помешают использованию сабжа (у офтопика багов на порядок больше, но он уже в ядре).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от нах.. (?), 24-Фев-26, 09:09   –6 +/
Это не ответ, это описание. Какие проблемы решает - это пример решения проблем, очевидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #19

16. Сообщение от Shellpeck (?), 24-Фев-26, 09:34   +2 +/
формидабл
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #20

17. Сообщение от cheburnator9000 (ok), 24-Фев-26, 10:08   –5 +/
В общем пока этот "язык" является языком для транспайлера для GCC он так и будет оставаться нишей для извращенцев и все.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

18. Сообщение от Axonic (ok), 24-Фев-26, 10:52   +2 +/
И в результате написание кода программы превращается в удовольствие, а скомпилированные бинарники быстрые. Что тебя беспокоит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #28, #41

19. Сообщение от нимнимним (?), 24-Фев-26, 11:19   +1 +/
- какие проблемы решаешь на работе?
- могу копать, могу картошку сажать, могу уравнения решать, могу людьми управлять
- хорошо, а решаешь какие?
- да двор подметаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #21

20. Сообщение от Аноним (20), 24-Фев-26, 13:07    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

21. Сообщение от Аноним (20), 24-Фев-26, 13:09   +/
Одно дело мести двор метлой, другой мести суперподметалкой Nim 2.2.8 всё равно мы пить не бросим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

24. Сообщение от zionist (ok), 24-Фев-26, 14:40   +/
> Язык компилируется в C, C++ и JavaScript

Странно, что не поддерживается IR LLVM или любой другой бэкэнд.

Ответить | Правка | Наверх | Cообщить модератору

25. Сообщение от Аноним (26), 24-Фев-26, 15:33   +/
Затрудняет распространение хороших языков. Здесь и управляющие отступы с питоноподобным синтаксисом, и империативный подход с разделением на инструкции и выражения, одновременно и сишная модель управления памятью с утечками и порчей памяти, и в то же время некая плюсовая, с несколькими видами счётчиков ссылок, требующая подгонки кода под каждый конкретный случай, и отсутствие компиляции, а только трансляция в си, что затрудняет отладку, и куча эпических ошибок в реализации практически всего, невыразительная система типов на уровне жабы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

26. Сообщение от Аноним (26), 24-Фев-26, 15:41   +/
>позиционируется как системный язык

С каких пор это стало важным?
>с акцентом на эффективность, безопасность памяти и удобство разработки

Под это определение условный руби подходит гораздо больше, чем nim. Там хотя-бы не нужно выбирать из сортов счётчиков ссылок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

28. Сообщение от Аноним (26), 24-Фев-26, 15:47   +1 +/
>написание кода программы превращается в удовольствие

Это вообще никак не влияет.
>а скомпилированные бинарники быстрые

Это далеко не лучший вариант достижения данной цели.
>Что тебя беспокоит?

Семантика си кода накладывает определённые ограничения на оптимизацию. Но даже это не важно, так как в превую очередь это затягивает время компиляции, плюс делает встроенную отладочную информацию в бинарнике вредной, так как место занимает, а толку от неё нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

29. Сообщение от Chester loved cheetos (?), 24-Фев-26, 15:48   +/
Людям свойственно повторять чужие ошибки. Так они получают уникальный опыт разработки, дав сообществу еще немного пищи для бытия. К сожалению, внимание подобным проектам чаще уделяют люди с избытком свободного времени. От незанятых в экономике, до лентяев. По этой причине в серьезный продакшн такие проекты не попадут никогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

30. Сообщение от Аноним (26), 24-Фев-26, 15:53   –1 +/
>Nim позиционируется как системный язык, подходящий для разработки от встраиваемых систем до веб-серверов

Шли долгие годы, люди старательно писали дырки на си, и тут вдруг вышел голанг, и оказалось, что сборщик мусора - это не так уж и плохо.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

31. Сообщение от Axonic (ok), 24-Фев-26, 17:36   +/
Глубина аргументации со стороны скептиков и их настойчивость намекают, что  язык, по меньшей мере, заслуживает внимания.

— Он быстрый.
— И что? Всё равно плохой вариант!
— На нём приятно создавать приложения.
— Это ни на что не влияет.
— Он генерирует си-код, чтобы хорошо отлаженные компиляторы собирали быстрые бинарники.
— Нет, семантика си-кода омерзительна!
— Но там нет семантики Си. Больше Modula, Oberon, Lisp и Python.
— Её не может не быть в таком языке. Язык плохой!
— Почему?
— Не используется в продакшене.
— А как же Ethereum Foundation?
— Ерунда! Дешёвые поделки!

Литературно обработал суть обсуждения.


Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #35

32. Сообщение от Аноним (26), 24-Фев-26, 18:03   +/
>Глубина аргументации со стороны скептиков и их настойчивость намекают, что  язык, по меньшей мере, заслуживает внимания.

Возьмите дыряшку, к ней скептики относятся гораздо теплее.
>Он быстрый.

Другие языки тоже быстрые, тысячи их.
>На нём приятно создавать приложения.

На других языках тоже приятно. Посмотрите на популярность того же си. Разве был бы он так популярен, если бы на нём было бы неудобно писать код?
>Он генерирует си-код, чтобы хорошо отлаженные компиляторы собирали быстрые бинарники.

Как минимум про llvm ir ыкспертам надо бы знать.
>Больше Modula, Oberon, Lisp и Python.

Да, да, конечно. Это такой lisp, без s-выражений. Ыксперты совсем не стесняются выдавать желаемое за действительное.
>Литературно обработал суть обсуждения.

Литературно показал свою безграмотность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #40, #45, #47, #48

33. Сообщение от Аноним (33), 24-Фев-26, 18:35   +/
>вышел голанг, и оказалось, что сборщик мусора - это не так уж и плохо.

После электрона действительно игого с жабой не кажутся злом, но это только кажется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #38

35. Сообщение от нах.. (?), 24-Фев-26, 19:07   –1 +/
>Литературно обработал суть обсуждения.

Так все верно. Вас спрашивают какую задачу решает язык, а вы начинаете про приятность, гладкость и шелковистость.

Дополню уровень литературности аналогией:
- в чем крут Вася?
- он приятный и хороший человек
- возможно, а в чем он крут?
- он быстрый
- у нас весь отдел не медленный
- он позиционируется как программист
- ????

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #43, #44

37. Сообщение от Аноним (37), 24-Фев-26, 20:09   +/
Инструмент этот убьёт одно: сложна система макросов. Макросы в высокоуровневых языках вообще хвост динозавра, который они тянут из ассемблера.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39, #42

38. Сообщение от Аноним (38), 24-Фев-26, 21:04   +/
ну в сравнении с жс они действительно не зло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

39. Сообщение от Axonic (ok), 24-Фев-26, 21:47   +/
Макросы в Nim и макросы в ассемблере — это вообще разные миры, даже если слово одно и то же. Они решают разные задачи, работают на разных этапах и обладают разной степенью «магии».

Макросы Nim работают на уровне абстрактного синтаксического дерева. Макросы ассемблера работают на уровне текстовой подстановки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #46

40. Сообщение от User097 (ok), 24-Фев-26, 22:38    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

41. Сообщение от menan (?), 24-Фев-26, 23:43    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

42. Сообщение от Аноним (42), 24-Фев-26, 23:51   +/
какие макросы, если им и без макросов не пользуются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

43. Сообщение от Alex (??), 25-Фев-26, 00:15   +/
>Вас спрашивают какую задачу решает язык

Я в Ниме не разбираюсь, но
вопрос немного странный. Вас интересует какую задачу решает язык? Или программы на этом языке? Или компилятор?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

44. Сообщение от Alex (??), 25-Фев-26, 00:17   +/
Ответьте сами, например, про язык С
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

45. Сообщение от Аноним (26), 25-Фев-26, 00:46   +/
>Nim по скорости решения реальных задач входит в первую пятёрку языков:

Очередной искуственный бенчмарк, к тому же ещё и не полный. В реальности, задача постановки шахматных фигур встречается слишком редко, чтобы о ней вообще вспоминать. Насколько же реальные задачи вроде отображения веб страниц на php, или разнообразных утилитах на go будут быстро работать, упирается в первую очередь в код на самих этих языках, так как два решения на одном языке будут иметь больший разрыв в производительности, чем два решения на разных языках. Если же брать условный c# и сравнивать его с nim, то c# в некоторых задачах будет даже быстрее.

Далее, в реальных задачах никто не гонится за каждой миллисекундой. Программа работает достаточно быстро, и этого достаточно. Разница между условным aot rust и jit node есть, но она не столь значительна, чтобы писать каждый проект на rust-е. А вот сложность написания кода на rust и на node можно увидеть практически сразу же, как минимум познакомившись с двусвязными списками. Если вы не заметили, то почему-то IDE очень часто пишут на Java. Поскольку в задаче "создать IDE" оказывается важным в первую очередь корретность и функциональность, а не то, как быстро она упадёт от повреждения памяти. Плюс играться с ручным управлением памяти программисты будут слишком долго, за это время можно реализовать какой-то функционал. Не нравится Java? Возмьмём Neovim, у которого плагины написаны на ВНЕЗАПНО Lua. Или Emacs, написанный на Elisp. Вот это и есть реальные задачаи.

Так вот, продолжая разговор о IDE на Java. К языку обычно предъявляются какие-то определённые требования. Например, для встраивания в веб страницу, ему необходимо транслироваться в маленький js. Или быть безопасным по памяти, как Java. Или ещё более надёжным, как Haskell или Ocaml. Или быть параллельным как Erlang. Вот тут, скорость языков типа си или nim начинает играть с ними злую шутку, так как из-за их общей ненадёжности, под нагрузкой они просто сыпятся. Там у массива не проверяются границы, тут переменная изменяемая, и всё, код складывается сам собой.

Насколько эти тесты вообще отражают хоть что-то, кроме погоды на Марсе, вопрос открытый.
https://github.com/attractivechaos/plb2/blob/1181b3b83fea52e... - 36 строк
https://github.com/attractivechaos/plb2/blob/1181b3b83fea52e... - 316 строк
В коде на c# массивы, в коде на Go почему-то структуры. Очень неадекватное тестирование.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

46. Сообщение от Аноним (26), 25-Фев-26, 00:52   +/
А зачем вам вообще макросы? Компилируется слишком быстро? Как вы код с макросами отлаживать собираетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

47. Сообщение от Аноним (26), 25-Фев-26, 00:56   +/
>Nim по скорости решения реальных задач входит в первую пятёрку языков:

И самое главное: Nim настолько быстрый, что у него уже ВТОРАЯ мажорная версия, а в нём продолжают баги выгребать. Программа может быть сколь угодно быстрой, если не важно, какой результат она возвращать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

48. Сообщение от Аноним (26), 25-Фев-26, 01:17   +/
Кстати вот как выгдлядит действительно быстрый язык https://habr.com/ru/articles/751462/
>TL;DR: декодер изображений PNG из стандартной библиотеки языка программирования Wuffs работает в 1.22–2.75 раза быстрее, чем libpng (широко используемая реализация PNG декодера на C с открытым исходным кодом), C-библиотеки libspng, lodepng и stb_image, а также самые популярные библиотеки для работы с PNG на Go и Rust.
>libpng написан на C, а значит он скорее всего имеет проблемы с memory safety. Более того, его API для обработки ошибок построен на setjmp и longjmp, а сотни goto усложняют статический или формальный анализ.
>Код libpng на самом деле невероятно сложен. Например грубая прикидка с помощью команды wc -l .c arm/.c intel/*.c в репозитории libpng даст нам 35182 строки кода (без учета заголовочных файлов). Аналогичная команда для Wuffs покажет нам 2110 строк. Конечно, libpng также реализует энкодер PNG, но даже с учетом этого остается разница примерно на порядок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32


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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру