Lune: Standalone Luau Runtime
39 comments
·May 21, 2025Dekkonot
miki123211
Luau also has some special features to make running untrusted user code.
Lua itself has a bit of a reputation for this, but it isn't quite true. For example, normal Lua doesn't really let you stop the execution of a program stuck in an infinite loop, either accidentally or maliciously.
merb
Does it compile to wasm? So that it is useful inside the browser?
Dekkonot
Luau itself does by design, but I've never tried compiling Lune to WASM. I know that there are some blockers with the Roblox library but that's an optional component and you can just leave it out.
The WASM build is actually what powers the demo on their website: https://luau.org/demo
ricardobeat
At this point I see it as turn-off when a project like this uses Rust. Slow, massive tooling and such a huge barrier to entry, when we have Go, Zig or just C (this ends up being largely backed by libc/ucrt anyway?).
parenwielder
It’s still early in its development, but the Luau team is building a first-party standalone runtime called Lute (https://github.com/luau-lang/lute) that’s in C++ because the language’s implementation is also in C++. That might be more your speed?
npalli
Looks good. Better chance of success. Agree with the OP you are responding to, Rust might be great for those looking to write things from scratch, no baggage to deal with, not so great if you have to use it when written by someone else (even if that 'someone' is you from one year ago).
ellg
whats the actual barrier? installing rust? looking at the instructions this doesnt seem much harder than installing zig or go?
codeflo
It isn’t, arguably easier than installing Go (no GOPATH). Rust compile times are really slow compared to Zig or Go though.
(Edit: As this seems to trigger some people: I code in Rust. I’m just stating the facts.)
ellg
Dont disagree that compile times are slower compared to alternatives in this space, although I'm not sure I'd quite describe that as some sort of barrier to entry from contributing
harryvederci
Just FYI: GOPATH isn't a thing anymore.
timschmidt
Rust compile times are *really* fast compared to running Zig or Go through a static checker and then a compiler, to arrive at similar confidence in the behavior of the code as a single run through rustc.
It sounds like maybe you're used to skipping part of the development process required for stable well-tested software. Maybe that works for UIs? Wouldn't want my runtime authors feeling that way.
lionkor
Where is the barrier and what does it look like? Other systems languages have similar complexity, even though it may not be obvious when they don't enforce all their rules
Heliodex
I can assume that Lune (and many of the Rust-based Luau runtimes that followed it) were written in Rust mainly because of the existence of mlua <https://github.com/mlua-rs/mlua> and the bindings it provides for Luau. Binding Luau in Zig or C isn't as plug-and-play but is still relatively easy, binding Luau in Go is a nightmare. I'm working on better Luau support for Go, and some support/binding libraries for other languages are also in development, which is awesome to see and will hopefully bring more language diversity to the Luau ecosystem.
90s_dev
Zig is just as much mental overhead. C and C++ are too, but most of us have amortized that cost already. Go is already a legacy language that probably shouldn't be used in production in most cases.
rafram
> Go is already a legacy language that probably shouldn't be used in production in most cases.
This is objectively not true. “Go feels legacy to me and I wouldn’t use it in production in most cases” is reasonable, if you feel that way, but “legacy language” has a definition, and Go isn’t a legacy language.
blizdiddy
Eager to hear any reply as to how you arrived at this take on Go. It feels like bait, but i like your projects and I’m willing to give you the benefit of the doubt.
90s_dev
From the beginning, the Go team always emphasized that it was basically just meant to replace Java and C++ for servers inside Google. One of the official Go doc pages starts off with a basically apologetic tone, saying something like "Go began back in 2007 when things were very different than they are now. C++ and Java were much worse, and that's basically what we were competing with." I can't find that page but being an official page, and having this kind of tone, already matches up with the tone the Go community always kind of had, of like, "it's not the perfect language and we acknowledge and own that fact, but at least it's better than the alternatives."
On top of this, in its excessive caution about adding features while balancing incidental and essential complexity, it just hasn't evolved and kept up to meet the kinds of demands modern languages do like Zig, Rust, C3, Carbon and Odin, and while these languages were innovating, Go was still catching up to 10-20 years ago at any given moment. It was already kind of a weird middle ground, not quite as high level as Ruby, not quite as low level as C++, and this slow catch up game plus lack of keeping up was, for me at least, just the nail in the coffin. But all of this together makes me personally think that it's just not a great fit for most scenarios, but also that it seemed to have started off on the wrong foot with itself and the wider programming community.
That's my take at least.
rstupek
What reasons would you have for classifying Go as a legacy language and why would you not use it in production?
euvin
Cool to see a niche tool I use suddenly on hacker news! I just use it to serialize Roblox game assets, but I do wonder how many people are out there using it for non-roblox purposes.
null
90s_dev
This looks like a great alternative to TypeScript + Node.js which I currently use.
My main gripe with Lua (and thus Luau) is colons. It's so easy to forget them. Does the type checker catch this error? And if so, does it catch it every time, provided you always use types? If so, that could be good enough for me. Especially if it has strong LSP + VS Code support.
parenwielder
Luau’s type system does arity checking and type checking for function calls, and even has a specialized error that detects when you probably meant to write a colon instead of a dot.
Moomoomoo309
Oh, Lua's type checker doesn't check function calls at all. Pass too few arguments? The rest are nil. Pass too many? The extras are dropped. An editor could check for it relatively easily (and some do, I think), but the language doesn't care at all.
debugnik
Is this true of Luau as well, which is the dialect used here? Or are you talking about just Lua (which doesn't have a type checker at all) or LuaLS?
I'd check for myself but Luau's web demo seems to lack the most important feature of their dialect, type checking.
parenwielder
Hi there, I’m from the Luau team. Just wanted to clarify that no, nothing they said about the type system is true of Luau. It reads like a comment about Lua’s runtime typechecking maybe (which is as limited as you’d expect from a dynamically typed language).
SkiFire13
> Lua's type checker
Lua has a type checker?
gsck
Do you mean colons for calling methods of an object, or semicolons at the end of lines?
LoganDark
Lua doesn't require semicolons at the end of lines. (Or lines at all.) Meanwhile accidentally using a period instead of a colon (field call instead of namecall) is completely semantically different (namecall passes self).
Disclaimer: I've contributed to Lune multiple times and have contributed off and on to Luau as well.
For those who aren't familiar, Luau is a language based on Lua that is developed and maintained by Roblox. It's entirely open source (you can see the repo here: https://github.com/luau-lang/luau) and it's diverged a fair bit from Lua at this point. Most notably, it's quite a bit faster than the PUC-Rio distribution of Lua, has native vector support, and has a type checker. It's not as fast as LuaJIT, but it's about as fast as you can expect for a non-JITed language and it has support for AoT compiling to native instructions on x86 and aarch64, so it can be basically as fast as LuaJIT for some tasks.
It's worth reading the website: https://luau.org/
Lune itself is nice and I use it for basically all of the scripting needs I have. Some of the API is limited compared to what you'd get in other runtimes (the obvious example is hashing, where it's just "string in, string out" instead of a stream that you can feed into and then finalize) but the logic is essentially that APIs should be "good enough" for the average user, not perfect. I think that's fine, but I'm also the one that wrote the hashing API so take it with a grain of salt. :-)