Moonstone: кроссплатформенная среда выполнения Lua, написанная на Zig, с интегрированным менеджером пакетов

Moonstone предлагает вернуть простоту Lua с современным инструментарием: единый бинарный файл, кроссплатформенную дистрибуцию, управление зависимостями. Это похоже на то, что Deno сделал для JavaScript.

Контекст

Lua — один из самых элегантных языков: небольшой, встраиваемый, быстрый. Его можно встретить в Neovim, в игровом движке Defold, в Roblox, в OpenResty. Но его экосистема оставалась фрагментированной: между vanilla Lua, LuaJIT и LuaRocks (историческим менеджером пакетов) распространение Lua-проекта порой напоминает археологическую экспедицию.

Moonstone (объявленный на Hacker News на этой неделе, ссылка на moonstone.sh) предлагает современный инструментарий: рантайм на Zig — то есть статически компилируемый, без рантайм-зависимостей — и встроенный менеджер пакетов. Принцип работы: moonstone add http-lib, moonstone run main.lua, moonstone build генерируют переносимый бинарный файл.

Почему Zig?

Zig (созданный Andrew Kelley в 2016 году) стал одним из любимых инструментов в low-level среде: нативная кроссплатформенная компиляция (zig cc работает как кросс-компилятор C), отсутствие GC, явное управление памятью, comptime. Написание рантайма на Zig даёт:

• Единственный статический бинарный файл, который можно собрать для Linux/macOS/Windows/ARM без зависимости от glibc или msvcrt
• Тривиальную кросскомпиляцию (zig build -Dtarget=aarch64-macos)
• Точный контроль над ABI для вызова C-библиотек через FFI (критично для Lua)

По сравнению с LuaJIT (Mike Pall, чистый C), Moonstone не выигрывает в скорости выполнения — LuaJIT остаётся непревзойдённым по производительности, — но выигрывает в портативности распространения.

Повторяющийся паттерн

Здесь мы видим тот же тренд, что и с Deno для JavaScript или Bun на сервере: вместо того чтобы собирать рантайм + менеджер пакетов + бандлер + task runner, один бинарный файл делает всё. Это паттерн all-in-one toolchain, который набирает популярность последние несколько лет, движимый желанием уйти от сложности npm/pip/pip-tools/tox.

Для Lua эта потребность реальна. LuaRocks работает, но опыт «я клонирую проект, делаю rock install, запускаю» далёк от такой же плавности, как cargo run в Rust или go run в Go. Moonstone нацелен на эту плавность.

Что нужно проверить

Проект молодой. Прежде чем использовать его в продакшене, стоит ответить на несколько вопросов:

1. Совместимость Lua 5.1/5.3/5.4: экосистема LuaJIT завязана на 5.1 с расширениями. Какую версию поддерживает Moonstone?
2. FFI и C-библиотеки: у LuaJIT есть свой FFI. Предлагает ли Moonstone что-то подобное или нужно использовать классический C API?
3. Интероп с LuaRocks: можно ли импортировать существующие rocks или весь экосистему нужно перепаковывать?
4. Совместимость байт-кода: читаются ли стандартным рантаймом предварительно скомпилированные .luac?

Эти ответы определяют будущее adoption. Новый инструментарий имеет ценность только если он не отрезает пути к существующему.

Конкретный пример использования

Где Moonstone может проявить себя уже сегодня? В сценариях автоматизации: CLI-инструменты, которые мы распространяем среди разработчиков на трёх ОС, не заставляя их устанавливать Lua. Или для модов к играм (Baldur's Gate 3, Fistful of Frags), где Lua — стандартный формат, но хочется современного tooling со стороны разработчика.

Кратко: Moonstone не призван заменить LuaJIT по производительности, это замена LuaRocks по UX. Две разные задачи, которые не стоит путать. Стоит присмотреться, если вы распространяете Lua для встраивания.