Good question. I’d say the Lua toolchain is still fragmented rather than having one obvious “state of the art.”, the one that got closest to that is Lux.
The established center is still LuaRocks for packages. Around it, people use different layers depending on the ecosystem: OpenResty has its own runtime/server world, as we know Neovim has its plugin conventions, games often use LÖVE, embedded apps usually vendor or tightly control Lua themselves, and tools like hererocks/Nix/asdf/mise/etc... are often used to pin Lua/LuaJIT versions.
Lux is worth mentioning as a newer Lua package manager/project tool, and I see it as adjacent rather than a direct enemy. Since you can use moonstone for solving the environment lua interpreter, and lux for packages side-by-side.
Moonstone is trying to sit in a slightly different space: reproducible Lua-family project environments. So not “a new Lua VM,” but a manager for interpreters, lockfiles, native C module builds, ABI compatibility, isolated envs, and mixed-runtime repos (plus some personal additions that I would have loved, such as open internal communications for custom CLIs.)
The pain point I’m aiming at is: “this repo needs Lua 5.4, this benchmark needs LuaJIT/OpenResty, this example uses LÖVE, and native modules need to rebuild correctly when ABI changes, and want to preserve it all clean and tidy”
Lua did not have an answer like cargo for rust, or UV for python... Till now.
Lua has a fragmentation issue, but it is also a feature not a bug.
You can embed the Lua VM in anything. That's one thing.
You can use it as a systems tool, installed by your distro, available like any other scripting language - for this, you will find it fragment'y and weird, unless you do things 'sensibly', ignore the distro, and build your ~/.local/lua5[1,3,jit]/ directory, yourself, with luarocks - note, I have done this successfully many times, all the way to distributable .deb, so I am biased - but this is a 'hidden' way to do Lua.
And then of course there are the frameworks and engines - folks who have put the LuaVM and all its glory into their own products and opened the REPL/.lua filesystem for business.
All of this is to say there is no one 'standard' Lua approach - you will find it in various forms. A lot of times, Lua is treated as an 'also-ran'/bastard-child' in distro policies, mostly because - I assume - the reasoning is that folks who are serious about Lua will get it onboard/compile it locally/use the engine, themselves.
$ luarocks-5.3 --local install turbolua # the way I've stayed 'sane', personally ..
I try not to be negative, but this software seems bizarre. It's a Lua meta manager written in Zig, that calls itself cross platform (Linux / MacOS only), and depends on external gnu build tools, not even the native Zig portable retargeting llvm.
LLMs are usually too busy agreeing to push back on the ideas & details like this.
More than one platform, different arch/ABI qualify as cross-platform, it is not stated as omni-platform... Zig CC (LLVM backed) is widely used across for materializing first-class C modules. It aims to leverage the Lua ecosystem then it is expected to rely on GNU tools for building legacy, already upstream and stablished LuaRocks packages, i.e. makefiles, or GCC dependent recipes. That is a pragmatic compatibility choice to use the existing Lua ecosystem out-of-the-box, while it is encouraged the use of moonstone native hermetic recipes (which rely on zig cc).
Contributions are greatly appreciated. Feel free to contact this email maximoverzini@gmail.com if you'd like to collaborate!
To give some context:
Moonstone is currently under heavy, messy(getting better with time), active development. As I build various Lua + Zig projects with it, API contracts, CLI routes + flags, and configurations are constantly shifting. Using AI co-authoring has been a bit of a survival mechanism to ensure the documentation doesn't fall completely out of sync with the codebase. That said, AI authored docs can definitely feel dry to the eye, and/or verbose. If you or anyone else would like to help prune, rewrite, or polish the documentation to make it read more naturally, I would be incredibly grateful for the help!
I suspect the AI docs will make it hard to find humans who want to contribute writing. Humans will want to contribute if they see that you value writing highly.
Huh. Are we using different versions, then? I'm using the one on addons.mozilla.org.
EDIT: I'm now seeing some numbers by usernames; I think that's just how many times you've upvoted that user's posts/comments, not the total upvotes on that particular comment.
Quick clarification because the HN title is easy to misread:
Moonstone is *not* (*EXTRA BOLD*) a Lua VM/runtime implemented in Zig.
It is a Lua environment and package manager written in Zig. It installs/selects Lua-family interpreters, resolves packages, builds native C modules, checks Lua ABI compatibility, creates isolated project environments(through symlinking), and stores artifacts in a content-addressed store.
So the closest mental model is:
LuaRocks + isolated project envs + lockfile replay + Zig-powered native builds + multi-interpreter workspace support. All batteries included for Lua development.
The project does use thematic names like “orbits” and “Ballad”; that’s an intentional design language, but the docs clearly need a stronger translation layer for first-time readers. I’m updating the landing/docs to lead with the concrete systems model first.
What is the current state of the art lua toolchain? Lua is king for dsl embedded in other software.
Used it for world of warcraft scripting and openresty http rules, that’s a wide range.
Good question. I’d say the Lua toolchain is still fragmented rather than having one obvious “state of the art.”, the one that got closest to that is Lux.
The established center is still LuaRocks for packages. Around it, people use different layers depending on the ecosystem: OpenResty has its own runtime/server world, as we know Neovim has its plugin conventions, games often use LÖVE, embedded apps usually vendor or tightly control Lua themselves, and tools like hererocks/Nix/asdf/mise/etc... are often used to pin Lua/LuaJIT versions.
Lux is worth mentioning as a newer Lua package manager/project tool, and I see it as adjacent rather than a direct enemy. Since you can use moonstone for solving the environment lua interpreter, and lux for packages side-by-side.
Moonstone is trying to sit in a slightly different space: reproducible Lua-family project environments. So not “a new Lua VM,” but a manager for interpreters, lockfiles, native C module builds, ABI compatibility, isolated envs, and mixed-runtime repos (plus some personal additions that I would have loved, such as open internal communications for custom CLIs.)
The pain point I’m aiming at is: “this repo needs Lua 5.4, this benchmark needs LuaJIT/OpenResty, this example uses LÖVE, and native modules need to rebuild correctly when ABI changes, and want to preserve it all clean and tidy”
Lua did not have an answer like cargo for rust, or UV for python... Till now.
Lua has a fragmentation issue, but it is also a feature not a bug.
You can embed the Lua VM in anything. That's one thing.
You can use it as a systems tool, installed by your distro, available like any other scripting language - for this, you will find it fragment'y and weird, unless you do things 'sensibly', ignore the distro, and build your ~/.local/lua5[1,3,jit]/ directory, yourself, with luarocks - note, I have done this successfully many times, all the way to distributable .deb, so I am biased - but this is a 'hidden' way to do Lua.
And then of course there are the frameworks and engines - folks who have put the LuaVM and all its glory into their own products and opened the REPL/.lua filesystem for business.
All of this is to say there is no one 'standard' Lua approach - you will find it in various forms. A lot of times, Lua is treated as an 'also-ran'/bastard-child' in distro policies, mostly because - I assume - the reasoning is that folks who are serious about Lua will get it onboard/compile it locally/use the engine, themselves.
I like the idea for this project, but not a huge fan of the AI-written docs.
I don't think it's just the docs that are LLM written.
I try not to be negative, but this software seems bizarre. It's a Lua meta manager written in Zig, that calls itself cross platform (Linux / MacOS only), and depends on external gnu build tools, not even the native Zig portable retargeting llvm.
LLMs are usually too busy agreeing to push back on the ideas & details like this.
More than one platform, different arch/ABI qualify as cross-platform, it is not stated as omni-platform... Zig CC (LLVM backed) is widely used across for materializing first-class C modules. It aims to leverage the Lua ecosystem then it is expected to rely on GNU tools for building legacy, already upstream and stablished LuaRocks packages, i.e. makefiles, or GCC dependent recipes. That is a pragmatic compatibility choice to use the existing Lua ecosystem out-of-the-box, while it is encouraged the use of moonstone native hermetic recipes (which rely on zig cc).
Contributions are greatly appreciated. Feel free to contact this email maximoverzini@gmail.com if you'd like to collaborate!
To give some context:
Moonstone is currently under heavy, messy(getting better with time), active development. As I build various Lua + Zig projects with it, API contracts, CLI routes + flags, and configurations are constantly shifting. Using AI co-authoring has been a bit of a survival mechanism to ensure the documentation doesn't fall completely out of sync with the codebase. That said, AI authored docs can definitely feel dry to the eye, and/or verbose. If you or anyone else would like to help prune, rewrite, or polish the documentation to make it read more naturally, I would be incredibly grateful for the help!
I suspect the AI docs will make it hard to find humans who want to contribute writing. Humans will want to contribute if they see that you value writing highly.
This just sounds like an excuse to complain about things without wanting to actually do anything about them.
I just don't get why docs are bashed for being AI written, while software gets praised by being AI written.
In every, single, new HN post.
I don't get how every post you make gets exactly 8 upvotes immediately.
In every, single, new comment.
(I don't really care, I just noticed it now. I honestly enjoy many of your comments.)
I don't get, how you found that out, as HN does not show post upvote?
Checking his profile multiple times for the total score and compare when a post was made?
Browser extension: Hacker News Enhancement Suite
I just installed that extension and it doesn't show the actual number of votes.
Weird, I see yellowapple (1).
Huh. Are we using different versions, then? I'm using the one on addons.mozilla.org.
EDIT: I'm now seeing some numbers by usernames; I think that's just how many times you've upvoted that user's posts/comments, not the total upvotes on that particular comment.
Lucky vibes.
Click. Couldn't resist your lucky charm, pjmlp (9).
i need to read the docs. i don’t need to read the code.
Lua works great on Nix. I don't get the urge to create more package managers.
Ah slight disappointment, first I thought it was a revival of the hack-n-slash Moonstone-game from the Amiga era.
But projects made in Zig are just as cool :)
Author here.
Quick clarification because the HN title is easy to misread:
Moonstone is *not* (*EXTRA BOLD*) a Lua VM/runtime implemented in Zig.
It is a Lua environment and package manager written in Zig. It installs/selects Lua-family interpreters, resolves packages, builds native C modules, checks Lua ABI compatibility, creates isolated project environments(through symlinking), and stores artifacts in a content-addressed store.
So the closest mental model is:
LuaRocks + isolated project envs + lockfile replay + Zig-powered native builds + multi-interpreter workspace support. All batteries included for Lua development.
The project does use thematic names like “orbits” and “Ballad”; that’s an intentional design language, but the docs clearly need a stronger translation layer for first-time readers. I’m updating the landing/docs to lead with the concrete systems model first.