luvit/luvit

Discussion to consider integration of Roblox's recently open sourced Luau

Reinitialized opened this issue · 5 comments

Roblox has recently opened their heavily modified but Lua 5.1 backwards compatible fork of Lua, called Luau. Luau includes a variety of improvements to Lua, from implementing a typing system to drastic improvements in both runtime and compiler performance. Instead of going into all the details here, I'll just leave the Luau website here. I think Luvit would hugely benefit from implementing Luau, making it a potential to become a competitor to NodeJS. Thoughts?

While Luau does introduce improvements to PUC Lua, benchmarks show that it continues to lag behind LuaJIT in interpreter performance (with JIT disabled). So introducing Luau in place of LuaJIT (Luvit's default runtime) would incur only performance losses, would lose out on both JIT compilation and LuaJIT's FFI interface.

Another glaring issue with Luau is that the Lua api that it exports does not use the C calling convention, rather it uses C++'s compiler-specific, name-mangling calling convention. This means that Luvi (the native portion of Luvit), along with all of the libraries it includes (such as lua-openssl, lua-compat5.3, lrexlib, lpeg and others) simply cannot use it, as they does not know or understand how to call the runtime in order to do anything.

I think Luvit would hugely benefit from implementing Luau, making it a potential to become a competitor to NodeJS

How would it benefit, and how would using Luau instead of LuaJIT enable any Lua runtime to become a competitor to NodeJS? Always assuming that this is actually a worthwhile or even realistic goal, and that there are enough people available to realize it.

I'm unclear on this part, since the biggest selling point of LuaJIT is speed (and a smaller one its FFI). The biggest selling point of NodeJS isn't just speed, it's also the large JS ecosystem and forced adaption of the language through browser vendors. Luau seems to offer no upgrades over LuaJIT (and Luvit) in any of these areas, so forgive me if I fail to see what integrating it would actually accomplish.

This is a weird suggestion no doubt. Assuming Luau had any benefits to its side (to my knowledge none), that would still require a whole rewrite of the whole Luvit ecosystem; each. single. one. That is not only a huge work to do, even bigger than the Luvit 3 rewrite, but it also sounds pointless sadly.

On the other hand, if the goal is to make Luvit a real competitor to Node.js, the right decision would be to rewrite the Luvit API to make it more compiling, better docs, bigger community targeting, etc; luckily, that's indeed the goal with the whole Luvit 3 rewrite. See Issue #1135.

Edit: Also do note, Luau most compiling selling point is its sandbox, something Luvit doesn't really need at all.

I wasn't logged in to the github for some reason but when I saw this issue, I couldn't stop myself logged-in again to make a comment here.

It seems like you do love Luau, no doubt there, we all love Lua in general anyway. Luau has different setup, it's true it has type system and some other cool feature, I must admit that's a good thing /BUT/ if you compare Luvit with Luau, you are out of your mind and your opinion seems so poor. Luvit in general doesn't need to be a competitor, every runtime has it's own benefit, why even bother with nodeJS? NodeJS itself has JIT functionalities, so do Luvit. Luau doesn't have the JIT yet, tho they are doing pretty impressive things but if we care about luvit's ecosystem, it's good how it is now.

Luau is no where near to Luvit or there nothing Luvit can be benefited from Luau at all.

I am now aware of the rework required from how Luau exposes its API (only compatible with C++), which in itself is a major roadblock. Maybe using the words "competitor" to NodeJS was a bad idea, but what I mean by this is in terms of having more options to build a project of choice without feeling locked into one ecosystem due to it's overwhelming dominance (making a Discord bot for example. I made one in Luvit in the past, and run into all sorts of issues due to lack of dependencies and weird little unexpected bugs, ultimately converting it to NodeJS due to it's overall stability and support).

I am also aware of the performance difference, which although seems relatively small to me, still does make an impact. In regards to Luau not being JIT, the reasoning behind this was due to iOS, as Roblox considered a JIT implementation in the past, but didn't want to make a split in performance differences between iOS and all other platforms which allowed JIT. With Luau now being open sourced, this may get changed either by Roblox or through a fork, but at the moment is an understandable concern.

The biggest reasoning I'm excited about Luau being open source is the amount of time invested into bringing both (from my understanding) a compiler and runtime Typed Lua, something not even TypeScript offers. This being the initial open source release of Luau, and being backed by a well funded company whose entire development API for end users is itself Lua, I imagine it'll only get better with time. My intent with this issue is to merely bring discussion to the table and see concerns such as the ones already brought up, along with potential interest as of this initial release.