Нативные бинарники, нативная производительность, не нужно никакого дополнительного рантайма/VM, всё портабельно (если под платформу есть Си компилятор — там вполне возможно использовать Nim).
А так есть все фичи для «удобства» написания программ — и автоматическое управление памятью, и исключения, и так далее, и всё быстро и удобно :)
Есть when defined (gcDestructors) — но это мало где нужно, в большинстве случаев никаких изменений не нужно, только если оптимизации именно для ARC (я про вещи типа sink/lent). И да, ARC — это automatic reference counting (ну и move semantics), это не atomic reference counting (некоторые путают с ARC в Swift)
Насчёт GC хотелось бы уточнить — конечно проводится много работы в сторону ARC/ORC, но дефолтным GC в будущем будем скорее всего ORC (ARC со сборщиком циклов). ARC сам по себе не является полноценным GC, это так. Просто немного неправильно звучит "избавиться от GC" :)
Ну --gc:arc уже можно использовать на 1.2, а он как раз может использоваться в hard realtime :) Конечно да, ещё не полностью стабильно, но не так уж и много времени осталось до того, как этот пункт станет реальностью
Как я уже написал в другом комментарии — в статье автор компилит и C, и Nim без оптимизации — если с полными оптимизациями, то скорость примерно равна.
Если честно — оригинальная статья очень плохая, просто идёт описание основного синтаксиса и т.д. Автор даже бенчмарк не смог нормально провести (!) — результаты Nim тут в полном отладочном режиме.
См. github.com/yakkomajuri/fibonacci-benchmark/issues/1 насчёт бенчмарка и forum.nim-lang.org/t/6577 для мнения от другого человека :)
refc годами работал и он очень стабилен, но уже долгое время вся работа идёт на ARC, и уже много прогресса — habr.com/ru/post/462577/#comment_21841990 для дополнительной информации :)
Что вы имеете ввиду под «отсутствие Объектов»? В Nim новые типы для хранения данных в основном определяются через «object»/«ref object». Конечно они не классы, но вполне себе объекты. При желании есть и наследование (единичное), и runtime dispatch (методы и мультиметоды). Правда всё-таки в основном предпочитается композиция и использование object variant'ов (что-то типа union структур в Си, но удобнее)
Таки хочется заметить — есть github.com/yglukhov/nimpy который позволяет использовать библиотеки Python'а в Nim, и наоборот — писать питоновские модули на Nim, всё через C API Python'а, обёрнуто в высокоуровневые макросы и типы.
Извиняюсь за бамп старого треда, но таки с LTO (который по сути можно «бесплатно» использовать с Nim, так как он компилируется в С) и статической линковкой с musl можно получить бинарники меньше 40-30кб, а так ещё если использовать LTO, ARC и --panics:on -d:noSignalHandler --opt:size при статической линковке с musl, то у меня от echo «Hello, world!» выходил статический бинарник <10кб размером :)
Извиняюсь, что отвечаю на комментарий полугодовой давности, но ARC это таки очень полезная вещь — ARC это по сути вставка компилятором различных хуков типа =destroy, = и так далее (всё это происходит благодаря compile-time data flow analysis и компилятор создаёт CFG), и reference counting. ARC и не будет дефолтным, т.к. он не может работать с циклами — для этого есть ORC (это ARC с добавленным собирателем циклов).
В ARC есть shared-heap, не нужно каких-то setupForeignThreadGc или похожих для работы с C библиотеками (или наоборот, если нужно писать shared библиотеку на Nim), ARC намного лучше для embedded.
Пока что планируется, что в 1.4 (может и позже, не знаю) ORC станет дефолтным GC (но это произойдёт как минимум тогда, когда сам компилятор будет работать с ARC/ORC и все популярные библиотеки).
Ещё с ARC возможно больше потенциальных оптимизаций благодаря анализу использования данных, к примеру вот самый недавний PR насчёт создания оптимизатора для ARC — github.com/nim-lang/Nim/pull/14962
Насчёт IRC — ему пока что нет ни одного аналога с таким же количеством разных клиентов и серверов. И да, он до сих пор используется большей частью разработчиков
nim-lang.org/blog/2020/10/16/version-140-released.html
Об оригинале на английском проводились обсуждения на:
Reddit: reddit.com/r/programming/comments/jbkerv/introduction_to_arcorc_in_nim
Hacker News: news.ycombinator.com/item?id=24786649
А так есть все фичи для «удобства» написания программ — и автоматическое управление памятью, и исключения, и так далее, и всё быстро и удобно :)
Есть when defined (gcDestructors) — но это мало где нужно, в большинстве случаев никаких изменений не нужно, только если оптимизации именно для ARC (я про вещи типа sink/lent). И да, ARC — это automatic reference counting (ну и move semantics), это не atomic reference counting (некоторые путают с ARC в Swift)
Насчёт GC хотелось бы уточнить — конечно проводится много работы в сторону ARC/ORC, но дефолтным GC в будущем будем скорее всего ORC (ARC со сборщиком циклов). ARC сам по себе не является полноценным GC, это так. Просто немного неправильно звучит "избавиться от GC" :)
См. github.com/yakkomajuri/fibonacci-benchmark/issues/1 насчёт бенчмарка и forum.nim-lang.org/t/6577 для мнения от другого человека :)
В ARC есть shared-heap, не нужно каких-то setupForeignThreadGc или похожих для работы с C библиотеками (или наоборот, если нужно писать shared библиотеку на Nim), ARC намного лучше для embedded.
Пока что планируется, что в 1.4 (может и позже, не знаю) ORC станет дефолтным GC (но это произойдёт как минимум тогда, когда сам компилятор будет работать с ARC/ORC и все популярные библиотеки).
Ещё с ARC возможно больше потенциальных оптимизаций благодаря анализу использования данных, к примеру вот самый недавний PR насчёт создания оптимизатора для ARC — github.com/nim-lang/Nim/pull/14962
Больше информации — www.youtube.com/watch?v=aUJcYTnPWCg (презентация Andreas'а с NimConf об ARC/ORC), forum.nim-lang.org/t/5734 (там в постах много интересного), nim-lang.org/docs/destructors.html про деструкторы (они являются важной частью ARC)