parenwielder

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

enough that we run a multibillion dollar business entirely off of executing untrusted code on our hardware

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

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?

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.

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

As long as Matthias is alive, you're not going to find out. He's not going to be removed from Racket, as much as you and many others here seem to believe there's some huge problem of "cancel culture" coming for "everyone brilliant."

Nobody tried to get him fired. They wanted him to not post inane and sexist bullshit on his office door.

And the last remaining not-Matthias person on your list, while not an academic descendent of his, (to the best of my knowledge) owes their current employment to Matthias' politicking.

needlessly antagonistic is a fair characterization of his approach to the world at large

I can assure you that while it certainly is easy for faculty to get away with this behavior (Matthias himself being evidence of that fact), his behavior is well outside of the range of what could reasonably be considered normal, at least within computing academia in general.

The link to the personal site was a byproduct of what he described as a "social experiment" in which he published the James Damore memo on his office door, and was offended that students reported him to the dean for acting to create a hostile work environment, rather than engage with him directly about the scientific merits of Damore's memo.

He describes this himself here: https://felleisen.org/matthias/Thoughts/Free_Speech.html

Matthias was the PhD advisor of Matthew Flatt and Shriram Krishnamurthi at the time where (what would eventually become) the Racket project started. Virtually all of the core contributors are either his PhD students over the years, or students of his former PhD students after they became professors. He's the project's steward, being the person primarily responsible for securing grant funding for the work that goes into Racket, and the project's "visionary" (as much as such a thing can really exist), being the one who has most explicitly philosophized the concept of "language-oriented programming" (though there are plenty of other researchers now interested in the subject, including independently from Matthias' lineage). It'd be difficult not to understate the importance he has had to the careers of his former students (both in terms of the research they've done and in terms of his support in doing the politics necessary to have a successful career in academia).

Frankly, if you haven't heard anything about it, it's because you are not a part of the community that Matthias is in (whether that be Racket or Academic Programming Languages). It's very far from a secret, though obviously people's individual tolerance for his behavior varies.

For what it's worth, if you wanted to make the argument that Racket the programming language would not exist without Matthew Flatt, you'd be undoubtably correct. He is more-or-less the sole maintainer of the compiler, but fortunately for everyone involved is a very nice guy.

Firstly, the high rating that Butterick received for his teaching (the highest of all the instructors) was given by the students, not Matthias.

Secondly, Matthias has lived in the United States for virtually his entire adult life. Longer than probably the majority of the posters here have been alive. The issue is not one of cultural differences or a misunderstanding. Matthias behaves this way consistently, is unapologetic for it, and when pressed will explain that his "challenging behavior" (i.e. abuse) is some kind of test of your ideas, your willpower, or your capacity for success.

Matthias is virtually always the prickliest person in the room at academic programming languages conferences, by quite a bit.

This is absolutely the key point, and the one that all the discussion here is missing. Nobody defends Matthias' behavior, they just suggest that you should tolerate or ignore it. The reason is clear when you realize that "the Racket community" is more-or-less analogous with "Matthias' academic descendants." The people who are working on Racket as a language owe immense professional debts to Matthias.

The person you've highlighted as doing everything is Matthew Flatt, a professor at the University of Utah, not Matthias Felleisen, whose contribution in code is not the reason he is indispensable to the project.