[mikulas_florek]

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.

[parenwielder]

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.

[Jyaif]

Have you considered using wasm as the foundation for Roblox, instead of Luau?

[parenwielder]

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.

[HaroldCindy]

Agreed. I think an underappreciated aspect of choosing a script VM in the space Roblox is in (user-generated content where scripts are content) your product is at the mercy of whoever controls your scripting implementation.

The scripting engine is an integral part of your product, and you need to "own" it end-to-end. Any bugs that creep into new versions of your scripting engine, any API breakage or design changes that impact your usecase are things that you are responsible for. Roblox owns the entire toolchain for Luau, and it's relatively small compared to the set of libraries required to compile to and execute WASM in a performant way.

The nuances of your typical JITing WASM runtime or V8 are pretty hard to learn compared to a simpler VM like Luau, it's a big reason why I've used Luau in my own projects.

[binary132]

how sandboxed is Luau really?

[parenwielder]

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

[westurner]

LunarEngine is built on raylib, which compiles to WASM. FWIU it might be possible to compile a Luau game to WASM with LunarEngine eventually.

"LunarEngine: An open source, Roblox-compatible game engine" (2025) https://news.ycombinator.com/item?id=44995147

[cloudmike]

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.

[mikulas_florek]

Fast hot reload is not Luau specific though. Lua and LuaJIT reloads fast too, so does JS and most other scripting platforms. In fact, I have subsecond C++ hot-reloads.

Do you have a link for the official Luau Discord? I can't see anything on their webpage or github and google is not helpful either.

[cloudmike]

I mentioned fast hot reload because your original comment complained about compilation speed, and some people might not know you were referring to the speed of compiling your custom Luau integration in C++ (which is also fast for me, personally).

Sounds like the Discord I mentioned is technically the Roblox discord. The #luau-lang and #luau-lsp channels are where I lurk.

[parenwielder]

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.

[jhatemyjob]

Thanks for name-dropping zeux. Didn't know about him.

[jhatemyjob]

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]

Yes, I mean Luau itself, not the scripts.

[jhatemyjob]

In that case, wouldn't incremental builds solve this?

[jwatte]

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]

Think they meant their C++ bindings for Luau, not Luau itself.

[mikulas_florek]

No, I mean Luau itself. I distribute Luau as dll by default, but without the analysis module, to keep it small (~600KB). If users want to have analysis, they need to build Luau from source. Bindings are not an issue, since they use only C API from Luau, which is fast to compile.