[HN Gopher] Lune: Standalone Luau Runtime
___________________________________________________________________
Lune: Standalone Luau Runtime
Author : erlend_sh
Score : 63 points
Date : 2025-05-21 14:51 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 90s_dev wrote:
| 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.
| gsck wrote:
| Do you mean colons for calling methods of an object, or
| semicolons at the end of lines?
| LoganDark wrote:
| 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).
| Moomoomoo309 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| debugnik wrote:
| Thanks, I suspected as much!
|
| Since you're here: Is it reasonably feasible for users to
| add declaration files for code exported from the host
| application? The lack of documentation got me stuck the
| last time I tried to embed Luau. Aside from that, I'm
| very excited about it!
| deviaze wrote:
| Yes! As an embedder you can write definition and
| declaration files! Declaration files are usually named
| like `globals.d.luau` and have a slightly different
| syntax than regular Luau. But it's really easy to set up
| global def files that you can pass to luau-lsp. Atm for
| my Luau runtime (seal), I have a small globals.d.luau and
| just bundle all the stdlib type files in a typedefs
| folder that gets included alongside my binary:
| https://github.com/deviaze/seal/tree/main/.seal
|
| This is just because definition files don't support doc
| comments yet (for hovers w/ luau-lsp)
| SkiFire13 wrote:
| > Lua's type checker
|
| Lua has a type checker?
| parenwielder wrote:
| 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.
| euvin wrote:
| 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.
| ricardobeat wrote:
| 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?).
| ellg wrote:
| whats the actual barrier? installing rust? looking at the
| instructions this doesnt seem much harder than installing zig
| or go?
| codeflo wrote:
| 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.)
| timschmidt wrote:
| 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.
| lvass wrote:
| Why run a static checker in every single machine you
| compile a project on if a developer already ran it
| elsewhere?
| timschmidt wrote:
| People who aren't developers generally install pre-built
| binaries. I know that's how almost every Linux
| distribution I've used for going on 30 years has worked.
|
| Developers, on the other hand, seem to need some help
| running static checkers regularly. Most don't seem to
| have well exercised CI toolchains doing it for them. Or
| aren't aware that they should be doing so - like
| yourself.
|
| Rust makes use of the tight integration between language,
| compiler, and checker to allow the language to be easier
| and more thoroughly checked than possible with checkers
| built for other languages. Many steps performed for
| compilation are reused. Which is what makes it so fast.
|
| If you think "why can't I skip this?" you have missed the
| point and are exactly the target developer these checks
| are for.
|
| I've written a lot of software. Never had a complaint
| about compile times in any language. The reality of
| developing with Rust is that after the first build, only
| changed files are rebuilt, which makes it just as fast to
| compile as any other language.
|
| If compile times are what concerns you about a language,
| that tells me you're not very far along in your career.
| You have a lot more problems to discover which are very
| much more serious. If you ever encounter the problems
| Rust solves, you'll grow to appreciate it's solutions.
| bbkane wrote:
| The smallest unit of compilation in Rust is the crate,
| not individual files unfortunately. That's why you'll see
| larger projects like Wezterm or uv use workspaces to try
| to tame compile times.
| timschmidt wrote:
| You're right that the crate, not the file, is the
| smallest unit of compilation.
|
| My largest rust project is still fairly small at around
| 8k lines across two dozen files. Still, it builds and
| links in 30 seconds on my workstation which is several
| years old and not particularly fancy.
|
| I could see this beginning to become an issue around 100k
| lines of code, but I'd think most people would be looking
| to split into multiple crates before that just for
| readability.
| eddd-ddde wrote:
| You can install pre built binaries if you are not
| concerned about developing new features.
| ellg wrote:
| 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 wrote:
| Just FYI: GOPATH isn't a thing anymore.
| 90s_dev wrote:
| 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 wrote:
| > 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.
| rstupek wrote:
| What reasons would you have for classifying Go as a legacy
| language and why would you not use it in production?
| blizdiddy wrote:
| 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 wrote:
| 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.
| blizdiddy wrote:
| So definitely more of a vibe take than rigorous case, but
| stated well enough. I'm over here working in production
| in Java 9 (we got off of 8 this month!) so there is an
| aspect of living in different worlds as well.
|
| Is it really fair to compare golang to languages that
| haven't hit 1.0? Would you sincerely use zig or carbon in
| production before Go?
|
| I just feel like "it's better than the alternatives" is
| still true, and will be for a while. I would love if
| software wasn't best written in slightly older languages,
| but even c++ had growing pains for years.
|
| If you compared it technically and semantically to stuff
| like swift or kotlin, i think the case would be stronger,
| but it's hard to take production concerns seriously when
| comparing it to zig. (I make a monthly donation to zig,
| but i wouldn't use it at work)
| 90s_dev wrote:
| Yeah to be fair by "production" I meant I personally
| wouldn't use it for a long-term (5-10 year) project. I'm
| sure it's fine in an enterprise scenario, or a client who
| really wants you to use it and is willing to pay to make
| it worth it.
|
| Honestly every language has warts, there are no perfect
| languages. I just personally don't like Go, mostly for
| the reasons stated above as well as in a recent article I
| can't find anymore but read a few weeks ago, mostly
| complaining about its well known ergonomics issues.
|
| But yeah it's fine to use in prod for the same reason
| Java 6 and IE 6 were for a long time: nothing really
| matters but money when you're doing _work_ work.
| 90s_dev wrote:
| Found it:
|
| https://go.dev/doc/faq#What_is_the_purpose_of_the_project
| parenwielder wrote:
| 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 wrote:
| 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).
| Heliodex wrote:
| 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.
| lionkor wrote:
| 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
| Dekkonot wrote:
| 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. :-)
| merb wrote:
| Does it compile to wasm? So that it is useful inside the
| browser?
| Dekkonot wrote:
| 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
| miki123211 wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-21 23:01 UTC)