|
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. |
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.