Moonstone: um runtime Lua multiplataforma escrito em Zig, com gerenciador de pacotes integrado

Moonstone propõe recuperar a simplicidade do Lua com uma cadeia de ferramentas moderna: binário único, distribuição multiplataforma, gerenciamento de dependências. Uma aposta que lembra o que o Deno fez pelo JavaScript.

O contexto

Lua é uma das linguagens mais elegantes que existem: pequena, embarcada, rápida. É encontrada no Neovim, no motor de jogo Defold, no Roblox, no OpenResty. Mas seu ecossistema permaneceu fragmentado: entre Lua vanilla, LuaJIT e LuaRocks (o gerenciador de pacotes histórico), a distribuição de um projeto Lua às vezes se assemelha a um percurso arqueológico.

Moonstone (anunciado no Hacker News esta semana, link para moonstone.sh) propõe uma cadeia de ferramentas modernizada: um runtime escrito em Zig — portanto compilado estaticamente, sem dependência de runtime — e um gerenciador de pacotes integrado. O princípio: moonstone add http-lib, moonstone run main.lua, moonstone build produzem um binário portátil.

Por que Zig?

Zig (criado por Andrew Kelley em 2016) tornou-se uma das ferramentas favoritas no cenário de baixo nível: compilação cross-target nativa (zig cc funciona como um cross-compilador C), sem GC, gerenciamento de memória explícito, comptime. Escrever um runtime em Zig traz:

• Um único binário estático compilável para Linux/macOS/Windows/ARM sem dependência de glibc ou msvcrt
• Uma cross-compilação trivial (zig build -Dtarget=aarch64-macos)
• Um controle fino sobre o ABI para chamar bibliotecas C via FFI (essencial para Lua)

Comparado ao LuaJIT (Mike Pall, projeto puro em C), o ganho não está na velocidade de execução — LuaJIT continua imbatível em performance — mas na portabilidade de distribuição.

O padrão que retorna

Encontramos aqui o mesmo movimento que o Deno para JavaScript ou o Bun no lado servidor: em vez de compor runtime + gerenciador de pacotes + bundler + task runner, um único binário faz tudo. É o padrão all-in-one toolchain que vem ganhando espaço nos últimos anos, impulsionado pelo desejo de fugir da complexidade do npm/pip/pip-tools/tox.

Para Lua, a necessidade é real. LuaRocks funciona, mas a experiência "clono um projeto, dou rock install, executo" está longe de ser tão fluida quanto cargo run em Rust ou go run em Go. Moonstone visa essa fluidez.

O que precisa ser verificado

O projeto é jovem. Antes de adotá-lo em produção, algumas questões:

1. Compatibilidade Lua 5.1/5.3/5.4: o ecossistema LuaJIT está ancorado no 5.1 com extensões. Moonstone suporta qual versão?
2. FFI e bibliotecas C: LuaJIT tem seu próprio FFI. Moonstone oferece um equivalente, ou é necessário usar a API C clássica?
3. Interop LuaRocks: é possível importar um rock existente, ou todo o ecossistema precisa ser reempacotado?
4. Compatibilidade de bytecode: os pré-compilados .luac são legíveis pelo runtime padrão?

Essas respostas condicionam a adoção. Uma nova cadeia de ferramentas só tem valor se não corta os laços com o existente.

Caso de uso concreto

Onde o Moonstone brilha hoje? Em scripts de automação embarcados: ferramentas CLI que distribuímos para devs em três sistemas operacionais diferentes sem obrigá-los a instalar Lua. Ou em mods de jogos (Baldur's Gate 3, Fistful of Frags) onde o formato Lua é padrão, mas queremos uma ferramenta moderna do lado do dev.

Para lembrar: Moonstone não é um substituto do LuaJIT em termos de performance, é um substituto do LuaRocks em termos de DX. Duas necessidades distintas, que não devem ser confundidas. Vale a pena acompanhar de perto se você distribui Lua embarcado.