Moonstone : un runtime Lua cross-platform écrit en Zig, avec gestionnaire de paquets intégré

Moonstone propose de retrouver la simplicité de Lua avec une chaîne d'outillage moderne : binaire unique, distribution cross-platform, gestion de dépendances. Un pari qui rappelle ce que Deno a fait pour JavaScript.

Le contexte

Lua est l'un des langages les plus élégants qui existent : petit, embarquable, rapide. On le retrouve dans Neovim, dans le moteur de jeu Défold, dans Roblox, dans OpenResty. Mais son écosystème est resté fragmenté : entre Lua vanilla, LuaJIT, et LuaRocks (le gestionnaire de paquets historique), la distribution d'un projet Lua ressemble parfois à un archéo-parcours.

Moonstone (annoncé sur Hacker News cette semaine, lien vers moonstone.sh) propose une chaîne d'outillage modernisée : un runtime écrit en Zig - donc compilé statiquement, sans dépendance runtime - et un gestionnaire de paquets intégré. Le principe : moonstone add http-lib, moonstone run main.lua, moonstone build produisent un binaire portable.

Pourquoi Zig ?

Zig (créé par Andrew Kelley en 2016) est devenu l'un des outils préférés de la scène système bas-niveau : compilation cross-target native (zig cc fait office de cross-compilateur C), pas de GC, gestion mémoire explicite, comptime. Écrire un runtime dans Zig apporte :

• Un seul binaire statique compilable pour Linux/macOS/Windows/ARM sans dépendance à glibc ou msvcrt
• Une cross-compilation triviale (zig build -Dtarget=aarch64-macos)
• Un contrôle fin sur l'ABI pour appeler les bibliothèques C via FFI (crucial pour Lua)

Comparé à LuaJIT (Mike Pall, projet C pur), le gain n'est pas la vitesse d'exécution - LuaJIT reste imbattable côté perf - mais la portabilité de distribution.

Le pattern qui revient

On retrouve ici le même mouvement que Deno pour JavaScript ou Bun côté serveur : au lieu de composer runtime + package manager + bundler + task runner, un seul binaire fait tout. C'est le pattern all-in-one toolchain qui gagne du terrain depuis quelques années, porté par le désir de fuir la complexité npm/pip/pip-tools/tox.

Pour Lua, le besoin est réel. LuaRocks fonctionne, mais l'expérience « je clone un projet, je fais rock install, je lance » est loin d'être aussi fluide que cargo run en Rust ou go run en Go. Moonstone vise cette fluidité.

Ce qu'il faut vérifier

Le projet est jeune. Avant de miser dessus en prod, quelques questions :

1. Compatibilité Lua 5.1/5.3/5.4 : l'écosystème LuaJIT est ancré sur 5.1 avec extensions. Moonstone supporte quelle version ?
2. FFI et bibliothèques C : LuaJIT a son propre FFI. Moonstone en propose-t-il un équivalent, ou faut-il passer par C API classique ?
3. Interop LuaRocks : peut-on importer un rock existant, ou tout l'écosystème est à ré-empaqueter ?
4. Bytecode compat : les précompilés .luac sont-ils lisibles par le runtime standard ?

Ces réponses conditionnent l'adoption. Une nouvelle chaîne d'outillage n'a de valeur que si elle ne coupe pas les ponts avec l'existant.

Cas d'usage concret

Où voit-on Moonstone briller dès aujourd'hui ? Sur les scripts d'automatisation embarqués : outils CLI qu'on distribue à des devs sur trois OS différents sans leur imposer d'installer Lua. Ou pour des mods de jeux (Baldur's Gate 3, Fistful of Frags) où le format Lua est standard mais où on veut un tooling moderne côté dev.

À retenir : Moonstone n'est pas un remplaçant de LuaJIT côté perf, c'est un remplaçant de LuaRocks côté DX. Deux besoins distincts, à ne pas confondre. À surveiller de près si vous distribuez du Lua embarqué.