Анонсирован Nimony: новый компиляторный бэкенд для Nim 3.0 на базе NIF

Проект нацелен на системы жёсткого реального времени, предлагает детерминированное управление памятью и переосмысленную обработку ошибок.

Сообщается о разработке нового компиляторного бэкенда и сопутствующего подмножества языка Nim, получившего кодовое наименование Nimony. Согласно публикации ведущего разработчика Nim, известного под псевдонимом Araq, данный проект представляет собой эволюционное развитие языка Nim, инкорпорирующее опыт многолетней эксплуатации и нацеленное на формирование базиса для будущей мажорной версии Nim 3.0. Выпуск Nimony запланирован на осень 2025 года.

Nimony позиционируется как реализация "оптимизированного, элегантного языка", который, хотя и является подмножеством текущего Nim 2.x, уже сейчас может представлять самостоятельную ценность. Основной фокус разработки направлен на обеспечение пригодности для систем жёсткого реального времени (hard real-time) и встраиваемых систем, при сохранении высокого уровня безопасности памяти.

Ключевые аспекты Nimony

Фокус на предсказуемости (WCET): Архитектура ориентирована на гарантированное время выполнения операций в худшем случае, исключая JIT-компиляцию и трассирующую сборку мусора.
Управление памятью на деструкторах: Предлагается единый механизм mm:atomicArc с семантикой перемещения, аналогичный Rust и C++, с явным разделением на ацикличные (по умолчанию) и цикличные объекты.
Переосмысленная обработка ошибок: Внедрение типа ErrorCode для унифицированной сигнализации об ошибках и возможность интеграции состояния ошибки непосредственно в объекты, дополняющие традиционные исключения с обязательной аннотацией {.raises.}.

Архитектура и детерминизм исполнения

Приоритет WCET и прямое отображение типов

Основополагающим принципом проектирования Nimony является достижение предсказуемости времени выполнения в худшем случае (Worst Case Execution Time, WCET). Это требование продиктовано ориентацией на системы жёсткого реального времени, где недетерминированное поведение недопустимо. Как следствие, архитектура Nimony исключает использование JIT-компиляторов и сборщиков мусора с трассировкой (tracing garbage collectors), поскольку их операции могут вносить непредсказуемые задержки.

Для достижения предсказуемости, примитивные типы данных (целые числа, символы) напрямую отображаются на машинные слова и байты соответствующей архитектуры. Композитные типы (структуры, объекты) формируются без использования косвенной адресации (indirection), размещаясь непосредственно в стеке или внутри других структур данных. Такой подход минимизирует накладные расходы и обеспечивает более прозрачное соответствие между исходным кодом и генерируемым машинным кодом.

Логотип и слоган языка программирования Nim.

Управление памятью: фокус на `atomicArc`

Деструкторы, семантика перемещения и обработка циклов

В области автоматического управления памятью (MM), Nimony отходит от многообразия опций, доступных в Nim 2.0, предлагая единственный стандартизированный режим: mm:atomicArc. Данный режим базируется на подсчете ссылок с использованием атомарных операций, дополненном семантикой перемещения (move semantics) и вызовом деструкторов при уничтожении объекта, что сближает подход с практиками, принятыми в Rust и современном C++.

Ключевым нововведением является явное разделение объектов на ацикличные и потенциально цикличные. По умолчанию объекты считаются ацикличными (.acyclic), что является новым поведением. Для типов данных, экземпляры которых могут формировать циклические ссылки, требуется явная аннотация прагмой .cyclic. Отмечается, что ведется разработка нового алгоритма сборки циклических ссылок, однако его готовность к промышленному использованию на данный момент не гарантирована. Преимуществом MM на основе деструкторов называется его композируемость: управление ресурсами, требующими освобождения (например, файловые дескрипторы, сетевые сокеты, каналы), интегрируется естественным образом через деструкторы соответствующих типов.

Обработка ошибок: Интеграция состояний и `ErrorCode`

Альтернативы исключениям и унификация кодов ошибок

Подход к обработке ошибок в Nimony претерпел значительные изменения. Выражается неудовлетворенность традиционными механизмами исключений и их эмуляцией через алгебраические типы данных (sum types). Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) для невалидных целочисленных значений. В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации.

Тем не менее, традиционный механизм исключений Nim сохраняется, но с одним важным уточнением: любая процедура, способная порождать исключение, теперь должна быть в обязательном порядке аннотирована прагмой {.raises.}. Это требование направлено на явное обозначение потенциальных нелокальных переходов управления.

В качестве альтернативы или дополнения вводится новый перечислимый тип ErrorCode. Данный тип является типобезопасным и требует исчерпывающей обработки всех возможных вариантов (аналогично case для enum). ErrorCode спроектирован с учетом возможности отображения на стандартные коды ошибок различных систем и протоколов, таких как POSIX errno, коды ошибок Windows API и статусы HTTP. Цель — унифицировать обработку ошибок между различными библиотеками и обеспечить возможность прямой трансляции системных ошибок (например, "диск переполнен") в соответствующие коды состояния (например, HTTP 507) без дополнительных преобразований. Использование ErrorCode также позволяет обрабатывать и распространять ошибки без выделения памяти в куче, что критично для обработки ситуаций нехватки памяти (OOM).

Обработка нехватки памяти (OOM)

Переопределяемый `oomHandler` и безопасная работа с `nil`

Обработка ситуаций исчерпания памяти (Out of Memory, OOM) в Nimony реализована с отходом от распространенной практики аварийного завершения программы ("die on OOM"). Вместо этого предлагается механизм, позволяющий приложению продолжить работу. Контейнеры и операции выделения памяти, которые не могут выполнить запрос, вызывают переопределяемый обработчик oomHandler. Реализация по умолчанию записывает размер неудавшегося запроса в потоко-локальную переменную и позволяет выполнению продолжиться. Состояние нехватки памяти для текущего потока может быть проверено вызовом threadOutOfMem().

Разработчик может предоставить собственную реализацию oomHandler, например, для логирования или аварийного завершения приложения, если такое поведение является предпочтительным. Важным аспектом является обработка операций конструирования ссылочных объектов (ref object), которые могут завершиться неудачей из-за OOM. В Nimony результат таких операций (например, через new или аналогичные конструкторы) может быть nil, и компилятор форсирует обработку этого случая аналогично работе с опциональными типами (Option), предотвращая таким образом ошибки разыменования нулевого указателя. В контексте процедур, аннотированных {.raises.}, возвращаемое значение nil может быть автоматически преобразовано в ErrorCode.OutOfMemError.

Улучшения обобщенного программирования

Полная проверка типов дженериков и роль концепций

Механизм обобщенного программирования (generics) в Nimony получил развитие по сравнению с Nim 2.0. Ключевое улучшение заключается в том, что полная проверка типов обобщенного кода теперь выполняется на этапе его определения, а не только при инстанцировании конкретными типами. Ожидается, что это позволит выявлять ошибки на более ранних стадиях компиляции, предоставлять более информативные сообщения об ошибках и улучшить поддержку со стороны средств разработки (IDE), в частности, автодополнение кода.

Концепции (concepts), уже присутствующие в Nim, сохраняют свою роль как механизм статического описания требований к типам-параметрам обобщенных функций и типов. Они позволяют формально указать, каким операциям или свойствам должен удовлетворять тип для использования в данном обобщенном контексте.

Унификация конкурентности и параллелизма

Единый `spawn` и параллельные циклы

Nimony стремится к унификации моделей асинхронного и многопоточного программирования под единой конструкцией spawn. Решение о том, будет ли задача, запущенная через spawn, выполняться в том же потоке (асинхронно) или в отдельном потоке из пула (многопоточно), принимается планировщиком во время выполнения (runtime). Это накладывает определенные требования на аргументы, передаваемые в spawn: они должны быть потокобезопасными.

Внутренняя реализация модели конкурентности будет основана на продолжениях (continuations), а компилятор будет выполнять преобразование программы в стиль передачи продолжений (Continuation-Passing Style, CPS). Отмечается, что сама конструкция spawn реализована не как встроенная возможность языка, а как плагин компилятора.

Параллелизм рассматривается как более простая задача по сравнению с конкурентностью. Для написания чисто параллельного кода, ориентированного на вычисления (например, обработка массивов данных), Nimony предложит специальные конструкции, такие как параллельные циклы for, обозначаемые оператором ||. Это позволит реализовывать параллельные алгоритмы без необходимости использования переменных потока управления (flow vars), что может быть удобно для задач научных вычислений или программирования для GPU.

Пример работы утилиты мониторинга системных ресурсов

Интерфейс системного мониторинга, иллюстрирующий контекст системного программирования.

Метапрограммирование через плагины компилятора

Эволюция макросов Nim

Система метапрограммирования Nim, известная своими макросами, в Nimony эволюционирует в сторону плагинов компилятора (compiler plugins). Плагины представляют собой код, который компилируется в нативные инструкции и выполняется на поздних стадиях работы компилятора, после этапа проверки типов. Это дает плагинам доступ к полной информации о типах и семантике анализируемого кода.

Обещаны улучшенные и более удобные API для разработки плагинов. Использование промежуточного формата NIF (Nim Intermediate Format) также должно упростить реализацию различных трансформаций кода. Плагины могут выполняться инкрементально и параллельно, что способствует повышению производительности компиляции.

Типы плагинов:

Плагины для шаблонов (Template Plugins): Привязываются к конкретным шаблонам и обрабатывают код, связанный с их вызовами.
Модульные плагины (Module Plugins): Получают на вход AST (Abstract Syntax Tree) всего модуля и должны вернуть преобразованное дерево. Конструкция spawn является примером реализации через модульный плагин.
Плагины для итераторов: Аналогичны плагинам для шаблонов, но применяются к итераторам.
Плагины для номинальных типов: Могут быть привязаны к определенным типам данных, заменяя механизм "макросов переписывания термов" (term rewriting macros) из Nim. Это позволяет реализовывать оптимизации, такие как устранение временных объектов при выполнении матричных операций.

Сравнение ключевых аспектов Nimony и Nim 2.x

В следующей таблице представлены основные различия в подходах между текущей стабильной веткой Nim (условно Nim 2.x) и проектируемым Nimony (цель Nim 3.0), основанные на опубликованных принципах дизайна.

Аспект	Nim 2.x (Типичный подход)	Nimony (Проектируемый подход)
Управление памятью (MM)	Множество режимов (refc, arc, orc, none, etc.)	Единый режим `mm:atomicArc` (деструкторы + move semantics)
Обработка циклов MM	Зависит от режима (orc/arc имеют сборщики циклов)	Явная аннотация `.cyclic`; новый сборщик циклов в разработке; `.acyclic` по умолчанию.
Обработка ошибок	Исключения (без обязательной аннотации), Result-типы	Исключения с обязательной `{.raises.}`; тип `ErrorCode`; интеграция ошибок в состояние объекта.
Обработка OOM	Обычно фатальная ошибка (зависит от MM и настроек)	Нефатальная ошибка; `oomHandler`; проверка `threadOutOfMem()`; `nil` требует обработки.
Проверка дженериков	В основном при инстанцировании	Полная проверка на этапе определения дженерика
Конкурентность/Параллелизм	Раздельные механизмы (async, threads, threadpool)	Унифицированный `spawn`; модель на продолжениях (CPS); параллельные циклы `\|\|`
Метапрограммирование	Макросы, шаблоны, term rewriting macros	Плагины компилятора (скомпилированные, пост-типизация), улучшенные API

Визуализация: Оценка дизайна Nimony

Представленная ниже диаграмма является субъективной оценкой ключевых характеристик дизайна Nimony в сравнении с условными показателями Nim 2.x и языка Rust, основанной на заявленных целях проекта Nimony. Оценка отражает предполагаемые сильные стороны нового подхода, такие как предсказуемость и унификация моделей.

Структура концепций Nimony

Для наглядного представления взаимосвязей между ключевыми элементами дизайна Nimony ниже приведена ментальная карта (mindmap), иллюстрирующая основные направления разработки.

mindmap root["Nimony (Nim 3.0 Compiler)"] id1["Ключевые цели"] id1a["Жесткое реальное время (Hard Real-time)"] id1b["Встраиваемые системы"] id1c["Безопасность памяти"] id1d["Предсказуемость (WCET)"] id2["Управление памятью (MM)"] id2a["mm:atomicArc (Единый режим)"] id2b["Деструкторы"] id2c["Семантика перемещения (Move Semantics)"] id2d["Обработка циклов"] id2d1[".acyclic (по умолчанию)"] id2d2[".cyclic (явная аннотация)"] id2d3["Новый сборщик циклов (в разработке)"] id3["Обработка ошибок"] id3a["Интеграция в состояние объекта (NaN, low(int))"] id3b["Потоко-локальная переменная ошибки"] id3c["Исключения с {.raises.} (Обязательно)"] id3d["ErrorCode (Типобезопасный enum)"] id3d1["Маппинг на errno, WinAPI, HTTP"] id3d2["Без аллокаций в куче"] id4["Обработка OOM"] id4a["Нефатальная ошибка"] id4b["oomHandler (Переопределяемый)"] id4c["threadOutOfMem() (Проверка состояния)"] id4d["Обработка nil как Option"] id5["Обобщенное программирование"] id5a["Полная проверка типов при определении"] id5b["Улучшенные сообщения об ошибках"] id5c["Улучшенная поддержка IDE"] id5d["Концепции (Concepts)"] id6["Конкурентность и Параллелизм"] id6a["Унифицированный spawn"] id6b["Планировщик времени выполнения"] id6c["Модель на продолжениях (CPS)"] id6d["Параллельные циклы ||"] id7["Метапрограммирование"] id7a["Плагины компилятора (Вместо макросов)"] id7a1["Компилируемые в нативный код"] id7a2["Работают после проверки типов"] id7a3["Доступ к полной информации о типах"] id7a4["Инкрементальные и параллельные"] id7b["Типы плагинов (Template, Module, Iterator, Type)"] id7c["Улучшенные API"]

Статус разработки и доступность

Разработка Nimony ведется активно. Ознакомиться с текущим состоянием проекта, открытыми вопросами и принять участие в обсуждении можно в репозитории проекта на платформе GitHub, в частности, в разделах Issues и Discussions. Обзор архитектуры компилятора также доступен для заинтересованных разработчиков.

Поддержка проекта осуществляется через платформу Open Collective. Ориентировочная дата выпуска Nimony, который ляжет в основу Nim 3.0, намечена на осень 2025 года.