Consider the possibility of adding luau support (via transpilation or other preprocessing steps)

[rdw-software]

This is another silly idea, which probably won't even work. Obviously, LuaJIT is the runtime and that's not going to change. BUT, what if there was a way to benefit from the luau tooling/ecosystem, optional typing (similar to TypeScript) regardless?

The runtime could accept .luau and convert it to .lua, to be executed by LuaJIT as usual. Is that even possible? I've literally never used luau, and I haven't thought about this at all beyond "that seems like a stupid crazy idea... so stupid it might just work?". FWIW, that's how webviews started... and I'd consider that a success, by and large.

There's also Pallene. But it clearly doesn't have the ecosystem, so the only real option for something like this is luau.

Anyway. I'll leave this here as a reminder and then forget about it. Maybe I'll look into this at some point, or maybe not.

[rdw-software]

A few random ideas, completely not validated or properly researched in any way:

• Could integrate the luau compiler itself and use it directly (conflicts with JIT APIs, no JIT/FFI support?)
• Could transpile to regular Lua like TypeScript does (allows JIT optimizations, but maybe too much overhead/complexity?)
• Could transform bytecode formats directly (performance TBD, but it might not allow using luau features inside their VM?)

[rdw-software]

I briefly looked at Luau recently (VERY briefly). Not sure if the selling points are really all that convincing? Maybe I'm missing something, but the only benefit would be typechecking/linting (similar to TypeScript). The performance of LuaJIT is clearly superior and there's no way to get the benefits of the type system and not use the LuaU compiler + VM, at least that's how it looked like.

So I guess this leaves as only "not completely ridiculous" option a scenario where .luau files could be converted to LuaJIT bytecode (assuming that is at all possible, or feasible... TBD) and then executed by the runtime as effectively regular Lua code.

Some options I would definitely consider questionable:

• Transpilation: The last thing I want is longer iteration times (even with Ninja, C++ build times are a noticeable drag)
• Two VMs: Just not happening, for simplicity's sake alone. I don't think managing two Lua states in parallel is a good idea
• Using LuaU instead JIT: Too slow, too immature, no FFI, performance is just all around "not there yet" (AFAICT)

Also, let's be real: If the choice is between relying on the ROBLOX creators or Mike Pall, there's no question whom I'd prefer.

---

That said, I am curious to explore the bytecode conversion idea and do some prototyping - if only to learn more about the topic.

[rdw-software]

I guess there are "selling points" that I didn't previously mention:

• LuaU sandbox: This is absolutely not needed here, and if it was I'd prefer something like Deno or the WOW API approach
• Batteries: Completely pointless here, as Evo provides more (and arguably better ones) by default - that's the whole point
• Familiarity: People who know ROBLOX but not other Lua-based ecosystems could have an easier time - fair, I guess (?)
• It's been claimed that the LuaU runtime uses types for more than just checking (but this wouldn't apply here as it's not viable)

Needless to say, I don't consider any of this compelling enough to "fully" integrate LuaU (at the VM level).

[rdw-software]

Possibly relevant for the bytecode experiment:

• https://github.com/uniquadev/LuauVM
• https://github.com/TheGreatSageEqualToHeaven/Fiu