6 ms·

Luau – Fast, small, safe, gradually typed scripting language derived from Lua

186 points by andsoitis 1y ago

ngrilly 1y ago
I learned about Luau via my 13 years old who is looking into Roblox Studio. That's how I ended up visiting luau.org and I'm quite impressed by Roblox's engineering on this.
- DashAnimal 1y ago
  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.
Ciantic 1y ago
Typed Lua is something I've always wanted, but writing a very comprehensive type-checker and LSP for another dynamic language is pretty difficult. All dynamic languages have similar problems to those TypeScript encountered, as most dynamic languages have a sort of structural typing in the form of dictionaries or objects. I do wonder if we could reuse TypeScript in other dynamic languages. Transform Luau to a subset of TypeScript, check with tsc, transform errors and results back to Luau. In the same way, one could reuse a TypeScript language server. This way of utilising TypeScript's engine could jump-start many other type checkers for other dynamic languages.
- cjbgkagh 1y ago
  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.
  - parenwielder 1y ago
    > Like a LLVM but for type systems instead of compilation / interpreters / JIT. This would be a very cool project, but depending on what you actually want out of it is basically open research in programming languages. Racket #langs and their general approach to type-checking are one sort of answer to this: it's basically a "language-building lab" with an underlying philosophy that we should all be approaching programming in a language-oriented way, that is, by building domain-specific languages that raise the level of abstraction for what you're talking about. That's probably the most developed approach to this sort of thing, but it's still very much something that the Racket folks continue to iterate on and design further. If you want more conventional _static_ type systems with a much harder delineation between "compile-time" and "runtime" than exists in Racket, you start getting into a sort of compiler-generator-framework territory with the type system, and you'd probably want a language for metatheory to program the type system in, and that starts to look like compiler-generator frameworks embedded into proof assistants like Agda or Rocq. There's some research in that space as well, but certainly nothing that has anything near universal agreement that it works well. Right now, the state-of-the-art for designing type systems for any language is essentially "employ a bunch of people with very, very deep specialization in this subject matter to painstakingly design and implement the type system with careful consideration of the runtime semantics of the language it's being built for." It's not easy, and it's not cheap, which is why the successful instantiations of this kind of thing are all massive corporate-backed projects. As someone who is really a type system designer first and a corporate-tech-worker a very distant second, I'd love to be able to democratize building type systems more (or to see that be democratized), but it feels very, very far away from being solved.
    - cjbgkagh 1y ago
      I would want to go further and use domain specialized analyzers and type systems that are extensible with 'design time' information, ala F# type providers. It is indeed still a research level project that needs multi-national corporation level funding and I doubt that'll happen any time soon. I think it's more likely that a programming languages designed for use by LLMs will spur some investment there - type system ergonomics are often limited by latency and LLMs can be both be more patient as well as learn not to rely on it as often. EDIT: Oh Hi! I didn't realize you're from the Luau team, cool, while Roblox isn't as big as Microsoft I wonder if it's a large enough multi-national to make a real dent in the research, I do hope you'll get your wish. I know I don't have the resources to take on such a project myself. I do type directed code generation which is about as close to the sun as I can safely fly.
- giraffe_lady 1y ago
  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.
- deviaze 1y ago
  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.
- dicytea 1y ago
  It already exists actually: https://github.com/TypeScriptToLua/TypeScriptToLua https://github.com/TypeScriptToLua/TypeScriptToLua. I had a pretty good experience with it while trying out Love2D.
  - Ciantic 1y ago
    That is one way. What I meant was transpiling Luau (in memory or cached to disk) -> TypeScript -> typecheck with tsc -> take error outputs and line numbers -> transform back to Luau code via sourcemaps etc. This is potentially way easier than making your own checker for another structurally typed language. User only sees Luau script in their editor, but it gets checked by TSC in the background. Roblox might is such a big maker that they can re-invent the whole structural typing themselves, so they don't need to do that.
pansa2 1y ago
How does Luau compare to Teal [0], which is described similarly as a "statically-typed dialect of Lua"? [0] https://teal-language.org/ https://teal-language.org/
- Scaevolus 1y ago
  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.
- cardanome 1y ago
  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.
- parenwielder 1y ago
  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.
pansa2 1y ago
Luau seems to be significantly more complex than Lua - I'm not sure it can still be called "small". Looking at the relative size of the implementations: Luau's is 120,000 lines of C++ [0], an order of magnitude larger than Lua 5.1's 14,000 lines of C. But I think that complexity is unavoidable for a gradually- or statically-typed language. Any language with a reasonably-complete type system is inevitably going to be much more complex than a dynamically-typed scripting language. [0] Counting *.cpp files in the "Analysis", "AST", "Compiler" and "VM" directories
- thomasmg 1y ago
  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 https://github.com/thomasmueller/bau-lang [2] https://github.com/thomasmueller/bau-lang/blob/main/src/test/java/org/bau/ena/test/Ena.md https://github.com/thomasmueller/bau-lang/blob/main/src/test... [3] https://www.reddit.com/r/ProgrammingLanguages/ https://www.reddit.com/r/ProgrammingLanguages/
- aw1621107 1y ago
  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.
  - HaroldCindy 1y ago
    To be fair, both `Analysis` (the type-checker, not necessary at runtime or compile time) and `CodeGen` (the optional JIT engine) have no equivalent in PUC-Rio Lua. If you look purely at the VM and things necessary to compile bytecode (AST, Compiler and VM) then the difference in code size isn't as stark. Having worked with both Lua 5.1 and Luau VM code, Luau's codebase is a heck of a lot nicer to work on than the official Lua implementation even if it is more complex in performance-sensitive places. I have mixed feelings on the structural typing implementation, but the VM itself is quite good.
eel 1y ago
It's a shame that Lua did not evolve in a more backwards-compatible manner. In addition to Roblox, lots of others projects started adopting Lua 5.1 as a scripting language in the late 00s. Lua itself is now at 5.4, but it did not keep backwards compatibility. LuaJIT and related projects pretty much only support 5.1. It's similar to the situation Python had with 2.x/3.x, except that the majority of Lua users I am aware of are preferring to stay with the older 5.1.
- thrance 1y ago
  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.
  - parenwielder 1y ago
    At the very least, there's a common core of Lua 5.1 that works across Luau, LuaJIT, and PUC Lua, so it's not as if there's no standardization here. We definitely aspire to include _more_ than just Lua 5.1 in Luau though.
- giraffe_lady 1y ago
  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.
- kragen 1y ago
  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.
- johnisgood 1y ago
  LuaJIT includes features from newer Lua versions (5.2 and 5.3), and more. See https://luajit.org/extensions.html https://luajit.org/extensions.html.
fithisux 1y ago
It is an impressive achievement. Unfortunately, there is not a Luau distribution of windows like Luarocks. Eventually we may see something in this place. The well known libraries, IUP, CD, IM have not been ported to Luau. But code is Free Open Source, who knows.
fasteo 1y ago
>>> Luau interpreter can be competitive with LuaJIT interpreter depending on the program To me, this is the more interesting bit of luau The performance page[1] contains a pretty good explanation of the work they have done. Pretty impressive engineering if you ask me. [1] https://luau.org/performance https://luau.org/performance
pull_my_finger 1y ago
I know everyone hates bringing up naming conflicts, but I'm just going to say I think it's pretty lame to name a language so deeply inspired by another language, a name that is also insanely close to said language. Even the logo... I mean there's paying homage, then there's whatever this is.
- guipsp 1y ago
  Luau was named Luau before Luau was a different language
valorzard 1y ago
Something that’s REALLY interesting is that Roblox is working on a Node.js style desktop runtime for Luau: https://github.com/luau-lang/lute https://github.com/luau-lang/lute
- bstsb 1y ago
  there's a slightly more mature runtime for Luau developed already: https://github.com/lune-org/lune 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
- esadek 1y ago
  There's another standalone Luau runtime called Lune: https://github.com/lune-org/lune https://github.com/lune-org/lune
Vosporos 1y ago
Coward, make it statically-typed!
mikulas_florek 1y ago
I used to use Lua and later LuaJIT in Lumix Engine. I switched to Luau because of its type system. However, it's apparent it was not meant to be used outside Roblox, as it has many rough corners. The documentation is not great, and the community is basically nonexistent - I got zero results when searching for any issues I encountered. Also, it's huge compared to Lua or LuaJIT, causing my project to compile 7x slower. The API is not great (e.g., an async API that blocks, using STL in the API, leaking STL headers). I encounter bugs with analysis/LSP often. Overall, I consider moving away from it.
- jhatemyjob 1y ago
  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?
  - mikulas_florek 1y ago
    Yes, I mean Luau itself, not the scripts.
    - jhatemyjob 1y ago
      In that case, wouldn't incremental builds solve this?
      - jwatte 1y ago
        Also, why would you need to compile it more than the one initial time? Are you actually making changes to Luau itself, rather than just using it?
        fourthark 1y ago
        Think they meant their C++ bindings for Luau, not Luau itself.
neoden 1y ago
Does it fix array indexing starting from 1?
merksoftworks 1y ago
This has been posted here a while ago but I'm pretty excited about bolt: https://github.com/Beariish/bolt https://github.com/Beariish/bolt - I've been looking for a statically typed language which could integrate well around something with a strong type system and good meta programming facilities for generating bindings. Bolt has the benefit of being a pretty small library with the downside of being nascent.
james2doyle 1y ago
I actually came across https://github.com/PlutoLang/Pluto https://github.com/PlutoLang/Pluto and it seems to be all the things you would want from Luau but without the connection to Roblox
- parenwielder 1y ago
  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.
  - james2doyle 1y ago
    https://pluto-lang.org/docs/New%20Features/Type%20Hinting https://pluto-lang.org/docs/New%20Features/Type%20Hinting They have "type hints" which looks to be pretty close to what luau has except they use `any` instead of `unknown` it seems
- mdaniel 1y ago
  heh, their custom package manager wrote its own dulwich https://github.com/PlutoLang/apm/blob/aca3620553ed7090552dbdf4a79bdfa91c4e0f45/gitwit.pluto https://github.com/PlutoLang/apm/blob/aca3620553ed7090552dbd...
benstigsen 1y ago
I can recommend that people check out Lune [1], it's a Luau runtime which includes a small but nice standard library. It's very easy to create something like a webserver in it. [2] [1]: https://lune-org.github.io/docs/ https://lune-org.github.io/docs/ [2]: https://lune-org.github.io/docs/the-book/5-networking/#running-a-web-server https://lune-org.github.io/docs/the-book/5-networking/#runni...
- catgirlinspace 1y ago
  My entire personal website runs on a fork of Lune! Only change is a (very jank) crate I wrote to add SQLite.
jll29 1y ago
I liked what I read, although the size of the original Lua embedded interpreter has a particular aesthetic that any type inference feature takes away (in return, you get type safety, it's a fair trade-off). But when I tried it without reading to much, I got this (bug or feature)? Code: --!strict local x: number = 2; print("Hello World!") x="test" print(x) Output: Hello World! test There wasn't any error message or warning when I pressed the run button, and that certainly violated my expectations, regardless whether the code and behavior may be considered "correct" (=documented) or not.
- parenwielder 1y ago
  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.
shmerl 1y ago
What is the reason that LuaJIT was never updated past Lua 5.1?
- whyenot 1y ago
  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-maintainers#google_vignette https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... I assume he's off somewhere with _why, questing for chunky bacon.
  - shmerl 1y ago
    Does it still lack maintainers today? Kind of surprising if no one picked it up when it's so actively used by major projects (like neovim and others). It blocks using more recent Lua for them.
    - whyenot 1y ago
      Mike Pall is still active occasionally, but there has been little development since 2017 and nobody else seems to have picked up the ball (but someone out there prove me wrong!).
    - pansa2 1y ago
      > Kind of surprising if no one picked it up LuaJIT’s code is very complex and esoteric, I don’t think anyone other than Mike Pall has done any significant work on it.
    - johnisgood 1y ago
      Why would you want "recent" Lua? LuaJIT includes features from newer Lua versions (5.2 and 5.3), and more. See https://luajit.org/extensions.html https://luajit.org/extensions.html.
    - krapp 1y ago
      That's fine. Freezing it at 5.1 (with some extensions) makes it stable. Not every language needs to move at the neck-breaking speed of, say, Javascript, pulling in every trend and bad idea that comes along for the sake of staying hip and exploding with unnecessary complexity and bloat. We need small, simple, sane languages. If you want to use a more recent Lua version, of course that's available. If you want to use LuaJIT then you know exactly what you're dealing with and that there won't be any weird surprises in the future.
Animats 1y ago
Second Life is switching over from Linden Scripting Language to Luau. It's working out well. The existing system compiled to Mono, and with Mono being deprecated (abandoned?) something new was needed. Amusingly, not only is Luau being supported, the LSL compiler is now targeting the Luau execution engine, and that works. Performance has improved slightly. Second Life runs on hundreds of thousands of tiny programs, all event driven and running on the servers. Managing that is tricky, since server side resources are limited. Yet it works well, even if user programs are compute-bound. Actually, the biggest problem is that each idle program uses about 1us per frame, which adds up.
- HaroldCindy 1y ago
  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 :)
  - Animats 1y ago
    (For those not familiar with Second Life, every object that does something has a little program in it. Every chair you can sit on, every door you can open, and every clothing item where you can change colors has a small program written by some users. Most of those programs are almost always idle. But there's a tiny amount of CPU time consumed on each frame for each idle program, about 1us to 2us in the Mono implementation. A region can have 10,000 little programs, each eating 1us on each simulation cycle, 45 times a second. This adds up.)
    - ChocolateGod 1y ago
      The amount of heavily custom scripted HUDs required to do things in Second Life seems pretty insane last time I checked it, one for a head, one for a body, one for animations etc. I'm surprised the viewer doesn't have a way to "dock HUDs" where they can be activated/deactivated with one click when not in use in viewer managed regions.
deleted 1y ago
[deleted]

186 points by andsoitis 1y ago

I learned about Luau via my 13 years old who is looking into Roblox Studio. That's how I ended up visiting luau.org and I'm quite impressed by Roblox's engineering on this.

DashAnimal 1y ago
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.

Ciantic 1y ago

Typed Lua is something I've always wanted, but writing a very comprehensive type-checker and LSP for another dynamic language is pretty difficult. All dynamic languages have similar problems to those TypeScript encountered, as most dynamic languages have a sort of structural typing in the form of dictionaries or objects. I do wonder if we could reuse TypeScript in other dynamic languages. Transform Luau to a subset of TypeScript, check with tsc, transform errors and results back to Luau. In the same way, one could reuse a TypeScript language server. This way of utilising TypeScript's engine could jump-start many other type checkers for other dynamic languages.

cjbgkagh 1y ago
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.
- parenwielder 1y ago
  > Like a LLVM but for type systems instead of compilation / interpreters / JIT. This would be a very cool project, but depending on what you actually want out of it is basically open research in programming languages. Racket #langs and their general approach to type-checking are one sort of answer to this: it's basically a "language-building lab" with an underlying philosophy that we should all be approaching programming in a language-oriented way, that is, by building domain-specific languages that raise the level of abstraction for what you're talking about. That's probably the most developed approach to this sort of thing, but it's still very much something that the Racket folks continue to iterate on and design further. If you want more conventional _static_ type systems with a much harder delineation between "compile-time" and "runtime" than exists in Racket, you start getting into a sort of compiler-generator-framework territory with the type system, and you'd probably want a language for metatheory to program the type system in, and that starts to look like compiler-generator frameworks embedded into proof assistants like Agda or Rocq. There's some research in that space as well, but certainly nothing that has anything near universal agreement that it works well. Right now, the state-of-the-art for designing type systems for any language is essentially "employ a bunch of people with very, very deep specialization in this subject matter to painstakingly design and implement the type system with careful consideration of the runtime semantics of the language it's being built for." It's not easy, and it's not cheap, which is why the successful instantiations of this kind of thing are all massive corporate-backed projects. As someone who is really a type system designer first and a corporate-tech-worker a very distant second, I'd love to be able to democratize building type systems more (or to see that be democratized), but it feels very, very far away from being solved.
  - cjbgkagh 1y ago
    I would want to go further and use domain specialized analyzers and type systems that are extensible with 'design time' information, ala F# type providers. It is indeed still a research level project that needs multi-national corporation level funding and I doubt that'll happen any time soon. I think it's more likely that a programming languages designed for use by LLMs will spur some investment there - type system ergonomics are often limited by latency and LLMs can be both be more patient as well as learn not to rely on it as often. EDIT: Oh Hi! I didn't realize you're from the Luau team, cool, while Roblox isn't as big as Microsoft I wonder if it's a large enough multi-national to make a real dent in the research, I do hope you'll get your wish. I know I don't have the resources to take on such a project myself. I do type directed code generation which is about as close to the sun as I can safely fly.
giraffe_lady 1y ago
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.
deviaze 1y ago
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.
dicytea 1y ago
It already exists actually: https://github.com/TypeScriptToLua/TypeScriptToLua https://github.com/TypeScriptToLua/TypeScriptToLua. I had a pretty good experience with it while trying out Love2D.
- Ciantic 1y ago
  That is one way. What I meant was transpiling Luau (in memory or cached to disk) -> TypeScript -> typecheck with tsc -> take error outputs and line numbers -> transform back to Luau code via sourcemaps etc. This is potentially way easier than making your own checker for another structurally typed language. User only sees Luau script in their editor, but it gets checked by TSC in the background. Roblox might is such a big maker that they can re-invent the whole structural typing themselves, so they don't need to do that.

pansa2 1y ago

How does Luau compare to Teal [0], which is described similarly as a "statically-typed dialect of Lua"? [0] https://teal-language.org/ https://teal-language.org/

Scaevolus 1y ago
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.
cardanome 1y ago
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.
parenwielder 1y ago
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.

pansa2 1y ago

Luau seems to be significantly more complex than Lua - I'm not sure it can still be called "small". Looking at the relative size of the implementations: Luau's is 120,000 lines of C++ [0], an order of magnitude larger than Lua 5.1's 14,000 lines of C. But I think that complexity is unavoidable for a gradually- or statically-typed language. Any language with a reasonably-complete type system is inevitably going to be much more complex than a dynamically-typed scripting language. [0] Counting *.cpp files in the "Analysis", "AST", "Compiler" and "VM" directories

thomasmg 1y ago
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 https://github.com/thomasmueller/bau-lang [2] https://github.com/thomasmueller/bau-lang/blob/main/src/test/java/org/bau/ena/test/Ena.md https://github.com/thomasmueller/bau-lang/blob/main/src/test... [3] https://www.reddit.com/r/ProgrammingLanguages/ https://www.reddit.com/r/ProgrammingLanguages/
aw1621107 1y ago
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.
- HaroldCindy 1y ago
  To be fair, both `Analysis` (the type-checker, not necessary at runtime or compile time) and `CodeGen` (the optional JIT engine) have no equivalent in PUC-Rio Lua. If you look purely at the VM and things necessary to compile bytecode (AST, Compiler and VM) then the difference in code size isn't as stark. Having worked with both Lua 5.1 and Luau VM code, Luau's codebase is a heck of a lot nicer to work on than the official Lua implementation even if it is more complex in performance-sensitive places. I have mixed feelings on the structural typing implementation, but the VM itself is quite good.

eel 1y ago

It's a shame that Lua did not evolve in a more backwards-compatible manner. In addition to Roblox, lots of others projects started adopting Lua 5.1 as a scripting language in the late 00s. Lua itself is now at 5.4, but it did not keep backwards compatibility. LuaJIT and related projects pretty much only support 5.1. It's similar to the situation Python had with 2.x/3.x, except that the majority of Lua users I am aware of are preferring to stay with the older 5.1.

thrance 1y ago
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.
- parenwielder 1y ago
  At the very least, there's a common core of Lua 5.1 that works across Luau, LuaJIT, and PUC Lua, so it's not as if there's no standardization here. We definitely aspire to include _more_ than just Lua 5.1 in Luau though.
giraffe_lady 1y ago
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.
kragen 1y ago
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.
johnisgood 1y ago
LuaJIT includes features from newer Lua versions (5.2 and 5.3), and more. See https://luajit.org/extensions.html https://luajit.org/extensions.html.

fithisux 1y ago

It is an impressive achievement. Unfortunately, there is not a Luau distribution of windows like Luarocks. Eventually we may see something in this place. The well known libraries, IUP, CD, IM have not been ported to Luau. But code is Free Open Source, who knows.

fasteo 1y ago

>>> Luau interpreter can be competitive with LuaJIT interpreter depending on the program To me, this is the more interesting bit of luau The performance page[1] contains a pretty good explanation of the work they have done. Pretty impressive engineering if you ask me. [1] https://luau.org/performance https://luau.org/performance

pull_my_finger 1y ago

I know everyone hates bringing up naming conflicts, but I'm just going to say I think it's pretty lame to name a language so deeply inspired by another language, a name that is also insanely close to said language. Even the logo... I mean there's paying homage, then there's whatever this is.

guipsp 1y ago
Luau was named Luau before Luau was a different language

valorzard 1y ago

Something that’s REALLY interesting is that Roblox is working on a Node.js style desktop runtime for Luau: https://github.com/luau-lang/lute https://github.com/luau-lang/lute

bstsb 1y ago
there's a slightly more mature runtime for Luau developed already: https://github.com/lune-org/lune 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
esadek 1y ago
There's another standalone Luau runtime called Lune: https://github.com/lune-org/lune https://github.com/lune-org/lune

Vosporos 1y ago

Coward, make it statically-typed!

mikulas_florek 1y ago

I used to use Lua and later LuaJIT in Lumix Engine. I switched to Luau because of its type system. However, it's apparent it was not meant to be used outside Roblox, as it has many rough corners. The documentation is not great, and the community is basically nonexistent - I got zero results when searching for any issues I encountered. Also, it's huge compared to Lua or LuaJIT, causing my project to compile 7x slower. The API is not great (e.g., an async API that blocks, using STL in the API, leaking STL headers). I encounter bugs with analysis/LSP often. Overall, I consider moving away from it.

jhatemyjob 1y ago
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?
- mikulas_florek 1y ago
  Yes, I mean Luau itself, not the scripts.
  - jhatemyjob 1y ago
    In that case, wouldn't incremental builds solve this?
    - jwatte 1y ago
      Also, why would you need to compile it more than the one initial time? Are you actually making changes to Luau itself, rather than just using it?
      - fourthark 1y ago
        Think they meant their C++ bindings for Luau, not Luau itself.

neoden 1y ago

Does it fix array indexing starting from 1?

merksoftworks 1y ago

This has been posted here a while ago but I'm pretty excited about bolt: https://github.com/Beariish/bolt https://github.com/Beariish/bolt - I've been looking for a statically typed language which could integrate well around something with a strong type system and good meta programming facilities for generating bindings. Bolt has the benefit of being a pretty small library with the downside of being nascent.

james2doyle 1y ago

I actually came across https://github.com/PlutoLang/Pluto https://github.com/PlutoLang/Pluto and it seems to be all the things you would want from Luau but without the connection to Roblox

parenwielder 1y ago
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.
- james2doyle 1y ago
  https://pluto-lang.org/docs/New%20Features/Type%20Hinting https://pluto-lang.org/docs/New%20Features/Type%20Hinting They have "type hints" which looks to be pretty close to what luau has except they use `any` instead of `unknown` it seems
mdaniel 1y ago
heh, their custom package manager wrote its own dulwich https://github.com/PlutoLang/apm/blob/aca3620553ed7090552dbdf4a79bdfa91c4e0f45/gitwit.pluto https://github.com/PlutoLang/apm/blob/aca3620553ed7090552dbd...

benstigsen 1y ago

I can recommend that people check out Lune [1], it's a Luau runtime which includes a small but nice standard library. It's very easy to create something like a webserver in it. [2] [1]: https://lune-org.github.io/docs/ https://lune-org.github.io/docs/ [2]: https://lune-org.github.io/docs/the-book/5-networking/#running-a-web-server https://lune-org.github.io/docs/the-book/5-networking/#runni...

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

jll29 1y ago

I liked what I read, although the size of the original Lua embedded interpreter has a particular aesthetic that any type inference feature takes away (in return, you get type safety, it's a fair trade-off). But when I tried it without reading to much, I got this (bug or feature)? Code: --!strict local x: number = 2; print("Hello World!") x="test" print(x) Output: Hello World! test There wasn't any error message or warning when I pressed the run button, and that certainly violated my expectations, regardless whether the code and behavior may be considered "correct" (=documented) or not.

parenwielder 1y ago
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.

shmerl 1y ago

What is the reason that LuaJIT was never updated past Lua 5.1?

whyenot 1y ago
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-maintainers#google_vignette https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... I assume he's off somewhere with _why, questing for chunky bacon.
- shmerl 1y ago
  Does it still lack maintainers today? Kind of surprising if no one picked it up when it's so actively used by major projects (like neovim and others). It blocks using more recent Lua for them.
  - whyenot 1y ago
    Mike Pall is still active occasionally, but there has been little development since 2017 and nobody else seems to have picked up the ball (but someone out there prove me wrong!).
  - pansa2 1y ago
    > Kind of surprising if no one picked it up LuaJIT’s code is very complex and esoteric, I don’t think anyone other than Mike Pall has done any significant work on it.
  - johnisgood 1y ago
    Why would you want "recent" Lua? LuaJIT includes features from newer Lua versions (5.2 and 5.3), and more. See https://luajit.org/extensions.html https://luajit.org/extensions.html.
  - krapp 1y ago
    That's fine. Freezing it at 5.1 (with some extensions) makes it stable. Not every language needs to move at the neck-breaking speed of, say, Javascript, pulling in every trend and bad idea that comes along for the sake of staying hip and exploding with unnecessary complexity and bloat. We need small, simple, sane languages. If you want to use a more recent Lua version, of course that's available. If you want to use LuaJIT then you know exactly what you're dealing with and that there won't be any weird surprises in the future.

Animats 1y ago

Second Life is switching over from Linden Scripting Language to Luau. It's working out well. The existing system compiled to Mono, and with Mono being deprecated (abandoned?) something new was needed. Amusingly, not only is Luau being supported, the LSL compiler is now targeting the Luau execution engine, and that works. Performance has improved slightly. Second Life runs on hundreds of thousands of tiny programs, all event driven and running on the servers. Managing that is tricky, since server side resources are limited. Yet it works well, even if user programs are compute-bound. Actually, the biggest problem is that each idle program uses about 1us per frame, which adds up.

HaroldCindy 1y ago
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 :)
- Animats 1y ago
  (For those not familiar with Second Life, every object that does something has a little program in it. Every chair you can sit on, every door you can open, and every clothing item where you can change colors has a small program written by some users. Most of those programs are almost always idle. But there's a tiny amount of CPU time consumed on each frame for each idle program, about 1us to 2us in the Mono implementation. A region can have 10,000 little programs, each eating 1us on each simulation cycle, 45 times a second. This adds up.)
  - ChocolateGod 1y ago
    The amount of heavily custom scripted HUDs required to do things in Second Life seems pretty insane last time I checked it, one for a head, one for a body, one for animations etc. I'm surprised the viewer doesn't have a way to "dock HUDs" where they can be activated/deactivated with one click when not in use in viewer managed regions.

deleted 1y ago

[deleted]