alt.hn

5/21/2025 at 2:51:38 PM

Lune: Standalone Luau Runtime

 https://github.com/lune-org/lune

by erlend_sh

5/21/2025 at 6:06:07 PM

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

by Dekkonot

5/21/2025 at 9:44:28 PM

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.

by miki123211

5/21/2025 at 6:18:04 PM

Does it compile to wasm? So that it is useful inside the browser?

by merb

5/21/2025 at 6:28:37 PM

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

by Dekkonot

5/22/2025 at 2:06:57 PM

Hey! Yet another long-term contributor to Lune, and this is something I've experimented with for a while, but it wasn't possible due to our heavy reliance on Tokio for async I/O for a while. That has recently changed though, so I'm curious if that has changed much. I might try again and report back here.

However, I should mention that there is another Luau runtime called cart which has the sole goal of being heavily portable across environments -- and it supports running within WASM! You can even interact with JS APIs and mutate the DOM to write websites with it, if you wanted to.

cart: https://github.com/crossapprt/cart

by CompeyDev

5/21/2025 at 4:17:26 PM

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

by ricardobeat

5/21/2025 at 6:02:42 PM

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?

by parenwielder

5/21/2025 at 7:13:44 PM

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

by npalli

5/21/2025 at 4:20:06 PM

whats the actual barrier? installing rust? looking at the instructions this doesnt seem much harder than installing zig or go?

by ellg

5/22/2025 at 8:04:35 AM 

  I can think of couple:
  - Toolchain size: Nim, Zig ~100MB; Rust >1.5GB
  - Compilation Times
  - Micro-dependency Culture

by archargelod

5/21/2025 at 5:12:48 PM

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

by codeflo

5/21/2025 at 7:02:30 PM

Just FYI: GOPATH isn't a thing anymore.

by harryvederci

5/21/2025 at 5:39:05 PM

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

by ellg

5/21/2025 at 5:17:06 PM

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.

by timschmidt

5/21/2025 at 5:35:56 PM

Why run a static checker in every single machine you compile a project on if a developer already ran it elsewhere?

by lvass

5/21/2025 at 8:12:36 PM

You can install pre built binaries if you are not concerned about developing new features.

by eddd-ddde

5/21/2025 at 5:42:20 PM

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.

by timschmidt

5/21/2025 at 8:04:50 PM

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.

by bbkane

5/21/2025 at 8:25:19 PM

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.

by timschmidt

5/21/2025 at 7:58:05 PM

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.

by Heliodex

5/21/2025 at 10:26:38 PM

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

by lionkor

5/21/2025 at 4:53:12 PM

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.

by 90s_dev

5/21/2025 at 5:00:56 PM

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

by rafram

5/21/2025 at 7:43:03 PM

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.

by blizdiddy

5/21/2025 at 8:09:35 PM

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.

by 90s_dev

5/21/2025 at 9:42:19 PM

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)

by blizdiddy

5/21/2025 at 9:48:01 PM

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.

by 90s_dev

5/21/2025 at 5:21:04 PM

What reasons would you have for classifying Go as a legacy language and why would you not use it in production?

by rstupek

5/21/2025 at 4:00:19 PM

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.

by euvin

5/21/2025 at 3:40:38 PM

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.

by 90s_dev

5/21/2025 at 6:00:30 PM

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.

by parenwielder

5/21/2025 at 4:08:28 PM

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.

by Moomoomoo309

5/21/2025 at 4:16:43 PM

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.

by debugnik

5/21/2025 at 5:58:58 PM

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

by parenwielder

5/21/2025 at 6:43:02 PM

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!

by debugnik

5/21/2025 at 7:55:32 PM

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)

by deviaze

5/21/2025 at 4:32:42 PM

> Lua's type checker

Lua has a type checker?

by SkiFire13

5/21/2025 at 3:47:46 PM

Do you mean colons for calling methods of an object, or semicolons at the end of lines?

by gsck

5/21/2025 at 3:55:16 PM

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

by LoganDark

5/22/2025 at 2:14:41 PM

[dead]

by CompeyDev

5/22/2025 at 12:26:39 AM

[dead]

by gitroom