29 октября 2026 года Homebrew обновил пакет Nim до версии 2.4.0, официально представленной днём ранее. Язык получил параллельную инкрементальную компиляцию, новый режим работы со строками и алгоритм управления памятью YRC для многопоточных программ. Эти возможности затрагивают скорость разработки, совместимость низкоуровневого кода и обработку связанных объектов в разных потоках.
Параллельная компиляция Nim сокращает время сборки, но зависит от структуры проекта
В Nim 2.4.0 появился режим --ic:on: компилятор может выполнять части работы параллельно и использовать инкрементальную сборку. Последняя означает, что при изменении программы повторная компиляция способна учитывать уже обработанные части проекта, сокращая лишнюю работу.
Разработчики приводят конкретное сравнение на компьютере с 16 физическими ядрами. Сборка самого компилятора Nim заняла 31 секунду с отключённым режимом и 25 секунд с включённым. Разница составила около 19%. Это результат одного указанного теста, поэтому ожидать точно такого же ускорения от любой программы нельзя: эффект зависит, в частности, от связей между импортируемыми модулями.
Параллельная сборка использует отдельные процессы. У этого решения есть ограничение: макросы, которые во время компиляции обращаются к глобальным переменным с пометкой .compileTime, в некоторых проектах потребуют доработки. Поэтому совместимость старого кода с --ic:on нельзя считать автоматической.
Новый режим коротких строк меняет правила работы с указателями
Переключатель --strings:sso включает оптимизацию коротких строк — Small String Optimization. Её идея состоит в том, чтобы хранить небольшие строковые значения непосредственно внутри структуры строки, сокращая потребность в отдельных выделениях памяти. Особенно чувствителен к устройству такого хранения код, который напрямую обращается к байтам строки через указатель.
Раньше в низкоуровневых операциях часто использовали выражения вроде addr s[i]. Для нового режима разработчики предлагают API с отдельными способами чтения и записи. Функция readRawData возвращает указатель для чтения, readRawDataStable нужна, когда адрес должен сохраняться при перемещениях строки, а пара beginStore и endStore предназначена для записи блока данных.
Что меняется для существующих библиотек? Если библиотека передаёт адрес содержимого строки в код на C или хранит такой указатель между операциями, прежние предположения о его стабильности могут оказаться неверными. При этом переход на новый API возможен постепенно: официальное описание подтверждает его работу и без включённого SSO. Обязательной переработки всех программ релиз не требует.
YRC позволяет обрабатывать циклические ссылки между потоками
В Nim уже существовал алгоритм управления памятью ORC. Он умеет освобождать объекты, которые ссылаются друг на друга по кругу, но его механизм обработки таких циклов рассчитан на связи внутри одного потока. Новый режим --mm:yrc расширяет этот сценарий на несколько потоков, разделяющих связанные объекты.
Циклическая ссылка возникает, например, когда объект A хранит ссылку на B, а B — ссылку обратно на A. Обычного подсчёта ссылок может быть недостаточно: каждый объект продолжает удерживать другой. YRC сочетает атомарный подсчёт ссылок с механизмом обнаружения циклов, охватывающих несколько потоков, без общей остановки всех потоков для сборки мусора.
За дополнительную возможность приходится платить ресурсами. В опубликованном разработчиками тесте orcbench YRC оказался примерно вдвое медленнее ORC и потреблял приблизительно вдвое больше памяти. Эти числа относятся к указанному бенчмарку, а не ко всем приложениям Nim. Выбор между ORC и YRC связан с тем, передаются ли связанные объекты между потоками и нужны ли циклические ссылки в такой архитектуре.
Типы-суммы и циклические импорты упрощают описание связанных частей программы
Nim 2.4.0 получил более компактную запись типов-сумм — типов, значение которых может принимать одну из нескольких заранее описанных форм. Например, результат вычисления может содержать число или сообщение об ошибке, а узел синтаксического дерева — представлять число, строку либо операцию над другими узлами.
Прежде для подобных конструкций требовалось явно описывать перечисление вариантов и поле-переключатель. Новая форма позволяет объявлять ветви непосредственно внутри case. Данные извлекаются через сопоставление с образцом, причём компилятор проверяет полноту разбора вариантов. Старый синтаксис case object остаётся доступным.
Появилась и возможность явно разрешать взаимные импорты модулей с помощью пометки {.cyclic.}. Раньше доступность объявлений в такой зависимости зависела от порядка инструкций; новая схема проверяет группу связанных модулей по этапам. Разработчики по-прежнему считают циклические зависимости нежелательной архитектурной практикой, однако для случаев, когда они неизбежны, теперь определён понятный механизм. Импорты без явной пометки сохраняют прежнее поведение, но считаются устаревающим подходом.
Отдельно представлен экспериментальный модификатор owned для ссылок с единственным владельцем. Он включается флагом --experimental:ownedRefs; авторы прямо предупреждают, что его правила ещё могут меняться и ломать совместимость исходного кода.
Версия 2.4.0 появилась в Homebrew 29 октября
Команда Nim объявила о стабильном выпуске 28 октября 2026 года. На следующий день, 29 октября, в официальном репозитории Homebrew приняли изменение формулы nim, заменив исходный архив версии 2.2.12 на 2.4.0. Это отдельное подтверждённое событие, связанное с распространением релиза среди пользователей пакетного менеджера для macOS и Linux.
Для установки и обновления через менеджер версий Nim авторы описали команды choosenim update self и choosenim update stable, указав актуальную для релиза версию choosenim 0.8.16. При этом новые возможности компилятора включаются отдельными параметрами: --ic:on, --strings:sso и --mm:yrc. Сам факт обновления установленного Nim не означает, что все три режима автоматически начнут использоваться проектами.
Nim 2.4.0 расширил возможности компилятора с разными компромиссами
Релиз затронул три самостоятельные области: время сборки, способ хранения строк и работу с циклическими ссылками между потоками. Для параллельной компиляции уже опубликован измеримый результат на 16-ядерной машине, а для YRC — данные о дополнительном расходе времени и памяти. Совместимость отдельных проектов с новыми режимами зависит от макросов, низкоуровневых обращений к строкам и архитектуры многопоточности. Универсальных показателей ускорения или расхода ресурсов для всех программ разработчики не приводят.
