Moonstone: a cross-platform Lua runtime written in Zig, with built-in package manager

Moonstone aims to bring back the simplicity of Lua with a modern toolchain: single binary, cross-platform distribution, dependency management. A bet that reminds what Deno did for JavaScript.

The context

Lua is one of the most elegant languages in existence: small, embeddable, fast. It is found in Neovim, in the Défold game engine, in Roblox, in OpenResty. But its ecosystem has remained fragmented: between vanilla Lua, LuaJIT, and LuaRocks (the historical package manager), distributing a Lua project sometimes resembles an archaeological journey.

Moonstone (announced on Hacker News this week, link to moonstone.sh) offers a modernized toolchain: a runtime written in Zig - therefore statically compiled, with no runtime dependency - and an integrated package manager. The principle: moonstone add http-lib, moonstone run main.lua, moonstone build produce a portable binary.

Why Zig?

Zig (created by Andrew Kelley in 2016) has become one of the favorite tools of the low-level system scene: native cross-target compilation (zig cc acts as a C cross-compiler), no GC, explicit memory management, comptime. Writing a runtime in Zig brings:

• A single static binary compilable for Linux/macOS/Windows/ARM without dependency on glibc or msvcrt
• Trivial cross-compilation (zig build -Dtarget=aarch64-macos)
• Fine control over the ABI to call C libraries via FFI (crucial for Lua)

Compared to LuaJIT (Mike Pall, pure C project), the gain is not execution speed - LuaJIT remains unbeatable in terms of performance - but distribution portability.

The recurring pattern

Here we see the same movement as Deno for JavaScript or Bun on the server side: instead of composing runtime + package manager + bundler + task runner, a single binary does everything. This is the all-in-one toolchain pattern that has been gaining ground for a few years, driven by the desire to escape the complexity of npm/pip/pip-tools/tox.

For Lua, the need is real. LuaRocks works, but the experience of "I clone a project, I do rock install, I launch" is far from being as smooth as cargo run in Rust or go run in Go. Moonstone aims for this fluidity.

What to check

The project is young. Before betting on it in production, a few questions:

1. Compatibility Lua 5.1/5.3/5.4: the LuaJIT ecosystem is anchored on 5.1 with extensions. Which version does Moonstone support?
2. FFI and C libraries: LuaJIT has its own FFI. Does Moonstone offer an equivalent, or do you have to go through the classic C API?
3. LuaRocks interoperability: can we import an existing rock, or does the entire ecosystem need to be repackaged?
4. Bytecode compatibility: are the precompiled .luac files readable by the standard runtime?

These answers condition the adoption. A new toolchain only has value if it does not cut the bridges with the existing ecosystem.

Concrete use case

Where does Moonstone shine today? On embedded automation scripts: CLI tools that we distribute to devs on three different OSes without requiring them to install Lua. Or for game mods (Baldur's Gate 3, Fistful of Frags) where the Lua format is standard but where we want modern tooling on the dev side.

To remember: Moonstone is not a replacement for LuaJIT in terms of performance, it is a replacement for LuaRocks in terms of DX. Two distinct needs, not to be confused. To be watched closely if you distribute embedded Lua.