Moonstone: un runtime Lua multiplataforma escrito en Zig, con gestor de paquetes integrado

Moonstone propone recuperar la simplicidad de Lua con una cadena de herramientas moderna: binario único, distribución multiplataforma, gestión de dependencias. Una apuesta que recuerda lo que Deno hizo por JavaScript.

El contexto

Lua es uno de los lenguajes más elegantes que existen: pequeño, incrustable, rápido. Se encuentra en Neovim, en el motor de juego Defold, en Roblox, en OpenResty. Pero su ecosistema ha permanecido fragmentado: entre Lua vanilla, LuaJIT y LuaRocks (el gestor de paquetes histórico), la distribución de un proyecto Lua a veces se asemeja a un parque arqueológico.

Moonstone (anunciado en Hacker News esta semana, enlace a moonstone.sh) propone una cadena de herramientas modernizada: un runtime escrito en Zig —por lo tanto compilado estáticamente, sin dependencia en tiempo de ejecución— y un gestor de paquetes integrado. El principio: moonstone add http-lib, moonstone run main.lua, moonstone build producen un binario portable.

¿Por qué Zig?

Zig (creado por Andrew Kelley en 2016) se ha convertido en una de las herramientas favoritas de la escena de bajo nivel: compilación nativa cross-target (zig cc funciona como cross-compilador de C), sin GC, gestión de memoria explícita, comptime. Escribir un runtime en Zig aporta:

• Un solo binario estático compilable para Linux/macOS/Windows/ARM sin dependencia de glibc o msvcrt
• Una cross-compilación trivial (zig build -Dtarget=aarch64-macos)
• Un control fino sobre el ABI para llamar a bibliotecas C mediante FFI (crucial para Lua)

Comparado con LuaJIT (Mike Pall, proyecto puro en C), la ganancia no está en la velocidad de ejecución —LuaJIT sigue siendo imbatible en rendimiento—, sino en la portabilidad de distribución.

El patrón que regresa

Aquí se repite el mismo movimiento que Deno para JavaScript o Bun en el servidor: en lugar de componer runtime + gestor de paquetes + bundler + task runner, un solo binario lo hace todo. Es el patrón all-in-one toolchain que gana terreno desde hace unos años, impulsado por el deseo de huir de la complejidad npm/pip/pip-tools/tox.

Para Lua, la necesidad es real. LuaRocks funciona, pero la experiencia «clono un proyecto, hago rock install, lo ejecuto» está lejos de ser tan fluida como cargo run en Rust o go run en Go. Moonstone apunta a esa fluidez.

Lo que hay que verificar

El proyecto es joven. Antes de apostar por él en producción, algunas preguntas:

1. Compatibilidad Lua 5.1/5.3/5.4: el ecosistema LuaJIT está anclado en 5.1 con extensiones. ¿Moonstone soporta qué versión?
2. FFI y bibliotecas C: LuaJIT tiene su propio FFI. ¿Moonstone ofrece uno equivalente, o hay que pasar por la API clásica de C?
3. Interoperabilidad con LuaRocks: ¿se puede importar un rock existente, o todo el ecosistema debe ser reempaquetado?
4. Compatibilidad de bytecode: ¿los archivos .luac precompilados son legibles por el runtime estándar?

Estas respuestas condicionan la adopción. Una nueva cadena de herramientas no tiene valor si corta los puentes con lo existente.

Caso de uso concreto

¿Dónde se ve a Moonstone brillar desde hoy? En scripts de automatización embebidos: herramientas CLI que distribuimos a desarrolladores en tres sistemas operativos sin obligarlos a instalar Lua. O para mods de juegos (Baldur's Gate 3, Fistful of Frags) donde el formato Lua es estándar pero queremos un tooling moderno del lado del desarrollo.

Para recordar: Moonstone no es un reemplazo de LuaJIT en rendimiento, es un reemplazo de LuaRocks en experiencia de desarrollo (DX). Dos necesidades distintas, no hay que confundirlas. A vigilar de cerca si distribuyes Lua embebido.