Discussion to consider integration of Roblox's recently open sourced Luau #1167
Replies: 7 comments 1 reply
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Just want to add in some notes about luvit moving forward. People keep referring to Luajit as dead - this is not true, the company I work for (fmad.io) recently engaged Mike P to add a bunch of awesome features to Luajit (interning strings and string buffers). We will be doing more, and its all going out to the main branch. Having used Lua for 20 years, and Luajit since its inception, I would highly recommend staying on the Luajit path. There are alot of updates coming, and its performance is lightyears above anything you will get from PUC. And most importantly, ffi - this is such a major beneficial feature its very hard to explain to people just how powerful it makes luajit. So, from my perspective, I would very much dissuade people from moving from luajit to Luau. The benefits are just not there, considering the amount of effort needed and time taken to make it happen. I also believe that languages DO NOT have to keep changing and having features added - luajit is a brilliant example of this. We spent around a year assessing alternatives to Luajit before getting MP on board. Im so glad we did, every other solution was going to be years to change over. Luajit + FFI + C.. has a deep archive of libraries and capability. And it is highly flexible. With the tools around luvit, luvi and luv you have a potential ecosystem that could easily be one of the most powerful hidden gems around. On the above suggestions. I think follow Tim's guidance here - extract some of the libraries (openssl etc) and consolidate and modernize what is available. I personally (my own company) have delivered a few solutions using luvit (albeit heavily miodified) for a number of different types of uses: web server for an entertainment management site, a simulation system with luvit as a backend manager for websockets and sim module intergrations, and I also made a little GUI attached to luvit using a couple of different systems. Its quite diverse and powerful. I would be interested in contributing, if there were clear goals forward for this. I would probably drop use of luvit if it went down the PUC route. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback. Is any of this work available for viewing? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. Some of the prototype work and the simulation system is - but luvit is only a backend so there isn't much to see. It is not open source (yet). It will be early next year. This site was originally all done with luvit - in less than 2 months (It has been converted to apache in recent times). I have a few open source luvit samples that were used for testing a number of methods used in these apps: Most of the above is 2-3 years or more old. A current system I am working on with luvit is a game server here: Supports modular game networking for the Defold game engine. Hope this is the sort of info you were wanting. Feel free to ask more on Discord if you need: dlannan#1808 |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions