Luau – Fast, Small, Safe, Gradually Typed Scripting Language Derived From Lua

Arseny Kapoulkine is an amazing engineer. Highly recommend following his blog or social media. Other than working on luau and the rendering engine at Roblox, he's also responsible for meshoptimizer which if you're in graphics you've most definitely heard of, and volk, which now comes packaged with the Vulkan SDK.

Like a LLVM but for type systems instead of compilation / interpreters / JIT. I don’t see why that couldn’t work.

My thinking in this space has always started from a type inferred MetaLanguage but starting from a dynamic language does enable some interesting options. I tend not to touch dynamic languages, even going so far as to use transpilers, but I definitely would be more open to the idea of working with them if they had TypeScript level of gradual type checking and tool support. As you mention such a bidirectional transpiler would work I guess for things that don’t translate it could just give up and that’ll be part of the gradual typing aspect.

I would love to have TypeScripts type system on a Lua runtime, so I’ve been keeping an eye on Luau.

It already exists actually: https://github.com/TypeScriptToLua/TypeScriptToLua.

I had a pretty good experience with it while trying out Love2D.

For all its success typescript demonstrates the downside of this approach. Like you said it's just difficult, and the end result of having every corner of the dynamic language expressible in the type system forces you into the most complex & novel type systems.

IMO a better approach is the one used by rescript and gleam. With a few careful restrictions of the target language you can fit it into a hindley-milner type system. These are extremely well understood, robust & usable, and give you a much smaller interface than the expansive turing complete one of TS.

I'm kind of surprised there's not an active project for a small ML language outputting lua code. I really wish gleam could pick it up as a third backend, it would be an amazing fit.

Luau already has Luau Language Server which works extremely well for vscode w/ nvim & zed support as well. It surfaces Luau's own diagnostics w/ autocomplete, strict type checking, etc., leading to a better DX (for me) than using Ruby or Python. I primarily use Luau as a shell scripting & general purpose programming language w/ my own runtime (ala node is to js) called seal. Many Roblox devs use a different (much more popular) runtime called Lune for Roblox CI/CD, unit & integration testing, etc.

Luau isn't "Lua but with types," but rather a language in the Lua family that has grown a powerful gradual type system with a _ton_ of type inference (this is in contrast to e.g. TypeScript which takes the approach more of "add annotations to get benefits"), as well as a growing number of additions to the language that we believe make it a more pleasant developer experience to use. We're very focused on preserving the general ability to embed the language readily and with low costs to binary size and so forth, but we're less ruthlessly committed to the language's simplicity (for both better and worse). Overall, the goal is an embeddable language related to Lua with a focus on developer tooling and a positive developer experience such that people actually want to (and enjoy) build(ing) software in the language, rather than e.g. build large C projects and then expose them to Lua.

Teal compiles teal files into plain Lua just like TS does for JS. So all the advantages and disadvantages apply.

Luau is a backwards compatible superset of Lua that comes with it's own performance-tuned runtime. It offers more than just gradual typing.

So they are very different things. You can use Teal in cases when you don't control the runtime. Like write a Love2d game or your neovim config in it. Anywhere where Lua runs, you can use teal.

On the other hand Luau can offer superior developer experience because you don't have a separate compile step. They can do a lot more things that are impossible with teal as they have their own runtime and types do not get erased by compiling.

Teal transpiles to Lua, but Luau is a fork of Lua. Luau can implement wider ranging changes, like improving interpreter performance and security or adding syntactic sugar.

Roblox has a market cap near $100B and has multiple developers working full-time on Luau.

To further elaborate, here's a more detailed breakdown of tokei's line counts for each of the directories you list + the CodeGen directory:

- Analysis: 62821 lines of C++ code, 9254 lines of C headers

- Ast: 8444 lines of C++, 2582 lines of C headers

- CodeGen: 21678 lines of C++, 4456 lines of C headers

- Compiler: 7890 lines of C++, 542 lines of C headers

- VM: 16318 lines of code, 1384 lines of C headers

Compare to Lua 5.1, which tokei says has 11104 lines of C and 1951 lines of C headers in the src/ directory.

Lua (and to a somewhat lesser extent Luau) are small in terms of the learned surface of the value language, not necessarily in terms of lines of code. That being said, any runtime use of the language needn't depend on Analysis, which is the biggest compilation unit by far.

Probably also worth mentioning that Analysis currently contains two full type system implementations because we've spent the better part of the past three years building a new type system to address a lot of the fundamental limitations and architectural issues that we'd run into after years of working on the original one. The new one is not without issues still, but is definitely very usable, and gets better and better every week. At some point in the future, we will clip the old one altogether, and that'll shave off some 30,000 lines of code or something.

I agree that static and especially gradual typing add complexity, but it's a very much smaller amount of complexity than we're talking about here, so in fact it is very common to encounter dynamically-typed scripting languages that are much more complex than some languages with excellent type systems.

I think you can implement a Hindley–Milner type checker in about a page of code, not the 2000 pages of code you're talking about.

I'm not sure what you mean by "complete". H–M is complete in the sense that it's decidable and doesn't leave any holes: programs that check statically are guaranteed not to have type errors at runtime. It handles higher-order functions and parametric polymorphism (generics) out of the box, it doesn't suffer from null pointers, and it can even handle mutability. And it's fully inferrable. There are various extensions to make it more expressive (GADTs, typeclasses, subtyping, linearity, tagged arguments) but even the basic HM system is already a lot more powerful than something like the type system of C or Java 1.7.

I have written a Lua type checker in the past and have delved enough into the Lua source code. For that reason I can say that Lua is particularly densely coded; Lua's 14K LoC is something more like 3--40K LoC when coded in the normal, less dense way. Lua is not necessarily small; it's just kinda concise.

I fully agree. Lua and Luau are impressive, sure, but they are not really "small" or "simple", in my view. I don't think the complexity is unavoidable however. There are many programming languages that are much simpler, but at the same time very expressive. I'm working on one of them currently named "Bau" [1], and I started working on a Lua-inspired VM [2] for a subset of this language. There are many languages like mine, most of them incomplete and not really popular, discussed in [3].

[1] https://github.com/thomasmueller/bau-lang [2] https://github.com/thomasmueller/bau-lang/blob/main/src/test... [3] https://www.reddit.com/r/ProgrammingLanguages/

I think it's even worse than that, luau and luaJIT have evolved in different directions than the official lua project, such that they are now all sublty incompatible with each others. They all branch from lua 5.1 but it feels like there isn't an offical standard anymore.

It's hard to get reliable numbers on this but I believe 5.1 and 5.2 are both more popular than 5.4 which has been out for five years now. And I don't think 5.3 ever surpassed either of them. I'm not sure about luajit it gets a lot of attention but I don't see it around all that much.

The huge difference is that the Lua community doesn't attack people publicly for maintaining backward compatibility, so it's generally pretty easy to write code that works across a wide range of Lua versions.

LuaJIT includes features from newer Lua versions (5.2 and 5.3), and more.

See https://luajit.org/extensions.html.

Luau was named Luau before Luau was a different language

There's another standalone Luau runtime called Lune: https://github.com/lune-org/lune

there's a slightly more mature runtime for Luau developed already:

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

i use it for build scripts and automating tasks for Roblox place files, it's pretty good for my use-case

Thanks for sharing your experience. I'm curious why it would cause your project to compile slower though? It's a scripting language, so you don't need to compile anything, right? Do you mean compiling the Luau VM itself?

We definitely intend on folks being able to use Luau outside of Roblox, and we know of a number of folks doing so quite successfully including Remedy Entertainment (Alan Wake 2), Digital Extremes (Warframe), GIANTS Software (Farming Simulator 25).

That being said, it has been historically hard to get major investment into work actively supporting growth of the language off-platform since our entire team is employed to work on the project by Roblox. We are nevertheless changing this though, and investing in the language outside of the platform. As some folks have already mentioned here, we have a general-purpose standalone runtime that we're developing called Lute that's focused on using Luau outside of Roblox to write general-purpose programs, and we're building a whole suite of Luau-programmable developer tools for the language atop it.

It takes time to build things, and the Luau ecosystem is definitely still very young as you've noted, but it's something that we care a lot about and are investing in considerably going forward. We 100% believe that the best thing for the health of the language and the ecosystem is to support more diverse users and more diverse use-cases.

I use Luau with my Unity game for all gameplay code (60k+ loc so far). I agree the docs could be improved, especially for custom integrations. The new type system + LSP aren't great together yet either, and I've been a little worried about the direction since zeux left the team.

But otherwise I really like it. My Luau code hot reloads almost instantly while the game is running, and my C++ project compiles quickly when I update it. I like that it provides sandboxing if you want to support modding. And there's an active community of people on the official Discord, which is better than nothing.

Pluto seems cool, and I hadn't heard of it! Looks like they don't have a type system though, so it's more in the flavor of "extensions to Lua 5.4" than actively growing the language in a different direction than Lua itself has been growing.

heh, their custom package manager wrote its own dulwich https://github.com/PlutoLang/apm/blob/aca3620553ed7090552dbd...

My entire personal website runs on a fork of Lune! Only change is a (very jank) crate I wrote to add SQLite.

The type system isn't set up to be "required" today. You can run code without typechecking, and if you used the demo or just ran the `luau` executable, that's what happened. In an embedded context, you could choose to e.g. require all code to typecheck before running the compiler on it, and then you'd get more of the experience you're probably expecting here, i.e. refusal to run because it didn't typecheck. This is part of how we exist in a world where we had millions of lines of Lua 5.1 code in the wild written by hundreds of thousands of developers that we suddenly, overnight, turned into Luau code.

After Mike Pall left (10 year ago, wow!), for all intents and purposes, development ground to a halt.

https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT...

I assume he's off somewhere with _why, questing for chunky bacon.

IIRC Mike Pall dislikes some features of newer versions, particularly 5.2’s _ENV.

It does support a number of features that are not in Lua 5.1, notably a JIT compiler and an FFI, as well as some features from PUC Lua 5.2. If you mean to ask why it hasn't broken compatibility with Lua 5.1, it's probably so it can keep existing LuaJIT code bases running.

One thing that was immediately apparent upon switching VMs was that a lot of the existing overhead was in scheduling, context switching and the implementation of the actual library functions like `llDoWhatever()`.

We haven't even used Luau's JIT at all yet, but preemptive scheduling of what's typically trivial glue code is much cheaper and easier with a VM that supports it as a natural consequence of its design versus transforming everything into a state machine at the AST or bytecode level for a VM that doesn't.

> Actually, the biggest problem is that each idle program uses about 1us per frame, which adds up.

More scheduler overhead to resolve :)

When they had the Luau beta regions up and running I gave it a whirl and it seemed performance was greatly improved over the old Mono system. Clicking "Save" was near instant to execute, great improvement to clicking save and waiting 10 seconds to know whether or not there's an issue in your script.

The only desire I have is if they could adopt FiveM-style helper functions which help wrap coroutines, namely being CreateThread(fn) and Wait(ms) (wrapper around yield inside that "thread") and Await/Promises (seems like someone already made an implementation for Luau? https://github.com/evaera/roblox-lua-promise)

FiveM adopting these makes it easy to make better performing scripts without having to mangle coroutines, which is vital given the Lua VM has to finish its current task before the frame is allowed to render.

https://github.com/citizenfx/fivem/blob/master/data/shared/c...