In the abstract, there’s more of a focus on being general purpose, rather than Lune providing e.g. Roblox file format parsing as a core feature.
Concretely, they’re pretty similar right now, but Lute exposes Luau’s parser which we’re using to build more developer tooling for Luau, including a linter, a codemod tool, and a package manager (and hopefully more in the future).
> 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.
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.
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.
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.
There's not an official Discord for Luau today (though it's something I've been considering setting up), but there is a Roblox open source community discord that the whole team is active in as part of our work on Luau.
I would say that the primary interest in building the type system is in supporting a better developer experience, both in terms of productivity (better autocomplete, go-to definition, etc.) and in terms of correctness (identifying bugs earlier, which is why we're actively concerned with having a _sound_ type system). There's a pretty limited surface of areas where we accept unsoundness today (outside of casting) and they're all connected to limitations of the type system that we've been working to resolve.
Longer-term, there's definitely some interest in how we could leverage types to support more optimized code, but it's been a notoriously difficult problem for gradually-typed languages in general, see [Is sound gradual typing dead?](https://dl.acm.org/doi/pdf/10.1145/2837614.2837630)
As it stands, we already have a high-performance, sandboxed VM that we are maintaining successfully, and our editor environment is decidedly _not_ multilingual for historical reasons/lack of investment. It'd be very, very expensive for us to see any of the advantages of wasm for the platform today, and it wouldn't really do anything about our existing need to support the millions of lines of code written in Luau today.
Also strategically, wasm is a massive project coordinated by a large number of companies, and it doesn't seem especially prudent to bet the success of a single multibillion dollar company and their entire platform on a project that they don't control the destiny of.
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.
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.
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.
Concretely, they’re pretty similar right now, but Lute exposes Luau’s parser which we’re using to build more developer tooling for Luau, including a linter, a codemod tool, and a package manager (and hopefully more in the future).