6 ms·

I'm mostly wondering, what does this have over regular Lua, especially now with 5.4?

by mid-kid 5y ago

deleted 5y ago
[deleted]
plorkyeran 5y ago
Type annotations are the main benefit. It's also much faster than Lua 5.1, but I don't know how it compares to 5.4.
- jay_kyburz 5y ago
  I really miss compound assignments and a continue statement. The if then else expressions look cool too. Would love to see these in the LuaJIT but I think its considered "done"
  - kzrdude 5y ago
    Mike Pall has added two sponsored projects in 2021 http://luajit.org/sponsors.html http://luajit.org/sponsors.html I sure hope he's the world's best paid Lua contractor
  - maxhou 5y ago
    implementation of continue from one luajit fork: https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77843b8e1fa6e5312726 https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77...
ketralnis 5y ago
I can tell you from my own experience that luajit, which also targets 5.1 compatibility, is _significantly_ faster than Lua proper. In using it I've never missed 5.2+ features. So I imagine luau has the same thing going for it.
- deleted 5y ago
  [deleted]
- pansa2 5y ago
  I would expect Luau to be significantly slower than LuaJIT though, because Luau doesn’t include a JIT compiler.
  - dangoor 5y ago
    True, but they claim to have gotten as fast as LuaJIT in many cases and, important for their use case, JIT doesn't work on some platforms (iOS): https://luau-lang.org/performance https://luau-lang.org/performance > On some workloads it can match the performance of LuaJIT interpreter which is written in highly specialized assembly.
    - dirkf 5y ago
      Note how it says: "match the performance of the LuaJIT interpreter" (emphasis mine). LuaJIT basically has two parts: an interpreter in handcrafted assembly which is quite a bit faster than the standard Lua VM, and the actual JIT, which is even faster. IIRC on iOS the JIT is not allowed but the interpreter is still there.
      - dangoor 5y ago
        Good catch! I missed the word interpreter in there.
krinchan 5y ago
Lua's biggest thing is that it's pretty easy to embed inside a C/C++ application safely, for relative definitions of "safe" spanning "preventing the Lua code from segfaulting your application" to "preventing the Lua code from doing anything you don't explicitly give it the ability to do". It's why you see it used as so many game's plugin architecture and why it was selected for NeoVim. So there is a very large ecosystem of Lua code that just lives in Lua 5.1 and doesn't really push forward at all. I haven't checked in on the situation for some time, but most people who write Lua are writing Lua for something like NeoVim or WoW or some other plugin for a larger project. Those projects have no interest in dealing with the slow reference VM for Lua >=5.2 at this time. Lua 5.2, 5.3, and 5.4 are more analogous to Python 2 to Python 3's level of change, rather than Python 3.9 to Python 3.10. These more recent versions of Lua 5.x are somewhat incompatible with each other, rather than just adding new language features. Most products settle on Lua 5.1 because that is what luajit, a very fast just in time compiling implementation of the Lua VM supports. Plans to further support to new versions for luajit are...well they exist.
- pansa2 5y ago
  > WoW [...] have no interest in dealing with the slow reference VM Does WoW use LuaJIT? I thought it used the reference Lua 5.1 VM, simply because that was the newest version when it was first released. > Plans to further support to new versions for luajit are...well they exist. I’m not sure it’ll ever happen. AFAICT LuaJIT is so complex that only its author, Mike Pall, understands it well enough to make major changes. He has expressed his dislike for several of the changes in Lua >= 5.2.
  - krinchan 5y ago
    > Does WoW use LuaJIT? I thought it used the reference Lua 5.1 VM, simply because that was the newest version when it was first released. I didn’t mean to imply WoW was using luajit, apologies. I was under the impression that over the years they have patched and fussed with code of the reference VM to resolve some performance pain points in the vanilla UI lua. Unfortunately, I can’t find the source for that. Regardless, I’ve always assumed that they had little interest in both rewriting their vanilla UI to newer versions AND starting over from square one trying to resolve any performance hiccups they hit.
wruza 5y ago
Lua 5, unlike other foobars, is a complete language from the start. You may see 5.x as 5.a, 5.b, 5.c and so on rather than as “evolution” versions. The second digit is more like flavor, and as e.g. 5.2 or LuaJIT user you don’t miss 5.4 features. Moreover, some people, me included, find some of 5.2, 5.3 and 5.4 experiments questionable. Why is it so? Usually, when a language unlike Lua “evolves”, it just lacks a flipping lot of core/meta features from the beginning, crutch-adding them later. So users long for 1.x+ version so much, because 1.x is still bullshit, for any x. In case of Lua, its 5.1 version had some flaws, but it already had (arguably) more powerful execution/data model-wise than e.g. python or js, and these flaws were related to what the latter two haven’t had at all (because to them Lua is Lisp, in a sense of blub paradox). Coroutines, environments, metamethods, etc. 5.2 solved all of the remaining problems one way, LuaJIT another way. Upgrading to >5.2 doesn’t really change much in a way it works, but it’s enough to break your existing codebase. So, “especially now” doesn’t have much weight in this case.

I'm mostly wondering, what does this have over regular Lua, especially now with 5.4?

deleted 5y ago

[deleted]

plorkyeran 5y ago

Type annotations are the main benefit. It's also much faster than Lua 5.1, but I don't know how it compares to 5.4.

jay_kyburz 5y ago
I really miss compound assignments and a continue statement. The if then else expressions look cool too. Would love to see these in the LuaJIT but I think its considered "done"
- kzrdude 5y ago
  Mike Pall has added two sponsored projects in 2021 http://luajit.org/sponsors.html http://luajit.org/sponsors.html I sure hope he's the world's best paid Lua contractor
- maxhou 5y ago
  implementation of continue from one luajit fork: https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77843b8e1fa6e5312726 https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77...

ketralnis 5y ago

I can tell you from my own experience that luajit, which also targets 5.1 compatibility, is _significantly_ faster than Lua proper. In using it I've never missed 5.2+ features. So I imagine luau has the same thing going for it.

deleted 5y ago
[deleted]
pansa2 5y ago
I would expect Luau to be significantly slower than LuaJIT though, because Luau doesn’t include a JIT compiler.
- dangoor 5y ago
  True, but they claim to have gotten as fast as LuaJIT in many cases and, important for their use case, JIT doesn't work on some platforms (iOS): https://luau-lang.org/performance https://luau-lang.org/performance > On some workloads it can match the performance of LuaJIT interpreter which is written in highly specialized assembly.
  - dirkf 5y ago
    Note how it says: "match the performance of the LuaJIT interpreter" (emphasis mine). LuaJIT basically has two parts: an interpreter in handcrafted assembly which is quite a bit faster than the standard Lua VM, and the actual JIT, which is even faster. IIRC on iOS the JIT is not allowed but the interpreter is still there.
    - dangoor 5y ago
      Good catch! I missed the word interpreter in there.

krinchan 5y ago

Lua's biggest thing is that it's pretty easy to embed inside a C/C++ application safely, for relative definitions of "safe" spanning "preventing the Lua code from segfaulting your application" to "preventing the Lua code from doing anything you don't explicitly give it the ability to do". It's why you see it used as so many game's plugin architecture and why it was selected for NeoVim. So there is a very large ecosystem of Lua code that just lives in Lua 5.1 and doesn't really push forward at all. I haven't checked in on the situation for some time, but most people who write Lua are writing Lua for something like NeoVim or WoW or some other plugin for a larger project. Those projects have no interest in dealing with the slow reference VM for Lua >=5.2 at this time. Lua 5.2, 5.3, and 5.4 are more analogous to Python 2 to Python 3's level of change, rather than Python 3.9 to Python 3.10. These more recent versions of Lua 5.x are somewhat incompatible with each other, rather than just adding new language features. Most products settle on Lua 5.1 because that is what luajit, a very fast just in time compiling implementation of the Lua VM supports. Plans to further support to new versions for luajit are...well they exist.

pansa2 5y ago
> WoW [...] have no interest in dealing with the slow reference VM Does WoW use LuaJIT? I thought it used the reference Lua 5.1 VM, simply because that was the newest version when it was first released. > Plans to further support to new versions for luajit are...well they exist. I’m not sure it’ll ever happen. AFAICT LuaJIT is so complex that only its author, Mike Pall, understands it well enough to make major changes. He has expressed his dislike for several of the changes in Lua >= 5.2.
- krinchan 5y ago
  > Does WoW use LuaJIT? I thought it used the reference Lua 5.1 VM, simply because that was the newest version when it was first released. I didn’t mean to imply WoW was using luajit, apologies. I was under the impression that over the years they have patched and fussed with code of the reference VM to resolve some performance pain points in the vanilla UI lua. Unfortunately, I can’t find the source for that. Regardless, I’ve always assumed that they had little interest in both rewriting their vanilla UI to newer versions AND starting over from square one trying to resolve any performance hiccups they hit.

wruza 5y ago

Lua 5, unlike other foobars, is a complete language from the start. You may see 5.x as 5.a, 5.b, 5.c and so on rather than as “evolution” versions. The second digit is more like flavor, and as e.g. 5.2 or LuaJIT user you don’t miss 5.4 features. Moreover, some people, me included, find some of 5.2, 5.3 and 5.4 experiments questionable. Why is it so? Usually, when a language unlike Lua “evolves”, it just lacks a flipping lot of core/meta features from the beginning, crutch-adding them later. So users long for 1.x+ version so much, because 1.x is still bullshit, for any x. In case of Lua, its 5.1 version had some flaws, but it already had (arguably) more powerful execution/data model-wise than e.g. python or js, and these flaws were related to what the latter two haven’t had at all (because to them Lua is Lisp, in a sense of blub paradox). Coroutines, environments, metamethods, etc. 5.2 solved all of the remaining problems one way, LuaJIT another way. Upgrading to >5.2 doesn’t really change much in a way it works, but it’s enough to break your existing codebase. So, “especially now” doesn’t have much weight in this case.