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

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.

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

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

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

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?

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

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

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

Just FYI: GOPATH isn't a thing anymore.

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

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

Found it:

https://go.dev/doc/faq#What_is_the_purpose_of_the_project

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)

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.

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

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.

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.

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.

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.

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.

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

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!

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)

> Lua's type checker

Lua has a type checker?

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

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