Да, вы правы, в 1.4 есть ARC в котором реализованы семантики перемещений + счётчик ссылок, ну и ORC, как надстройка над ARC, но именно семантик владения нет — планируется реализовать https://github.com/nim-lang/RFCs/issues/144 в Nim 2.0 (https://github.com/nim-lang/RFCs/issues/177 — "#144 is not dead but scheduled for Nim version 2 which is a couple of years away. "), но не сейчас (много кода нужно изменять и так далее).
Как по мне, для Borrowing & Owning нужно изменять весь язык, что далеко не является лучшим решением :) С ARC/ORC изменений в код вообще вносить не нужно (кроме редких случаев, например порядка финализаторов, которые использовались с refc)
Нативные бинарники, нативная производительность, не нужно никакого дополнительного рантайма/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 — ему пока что нет ни одного аналога с таким же количеством разных клиентов и серверов. И да, он до сих пор используется большей частью разработчиков
Так почему же тогда Electron приложения жрут по 500мб, в то время как нативные кушают раз в 10 меньше? Я понимаю, что это из-за постоянного повышения производительности компьютеров, но не нужно выходить за рамки
Можете попробовать Nim, там тоже нативный код с опциональным GC, к тому же ведётся работа над деструкторами, кросс-компиляция как в Си (Nim компилируется в Си), никаких виртуальных машин и максимальная производительность (на уровне близком к чистому Си при правильном использовании языка)
К тому же там как раз планируется большое кол-во изменений в отношении к GC — деструкторы, которым не нужен GC (в компилятор добавился новый проход «destroyer», в котором в код будут вставляться вызовы деструкторов в нужных местах), к тому же строки и последовательности станут свободными от GC (уже есть эксперименты с этим).
В IRC/Gitter можете пообщаться на эту тему с Araq (создателем языка).
Уже давно есть декомпиляторы и деобфускаторы, с которыми можно смотреть С# (конечно код далеко не всегда идентичен оригиналу). Посмотрите на ILSpy, dnSpy (мне больше всего он нравится), dotPeek.
Из деобфускаторов наверное de4dot
Тоже относится к рекапче:
У меня месяца три назад рекапча ВСЕГДА начала спрашивать полную проверку (выбрать картинки и т.д), и с тех пор я не могу от этого избавиться.
Не зависит от моего браузера/ос/гугл аккаунта, просто постоянно требуется полное подтверждение.