7 ms·

Lapis + MoonScript + OpenResty looks like a lot of fun, so I was just starting to get a local environment running for it and immediately ran into the Lua 5.1 an

Lapis + MoonScript + OpenResty looks like a lot of fun, so I was just starting to get a local environment running for it and immediately ran into the Lua 5.1 and 5.2+ divergence. For someone who has just been a casual observer of the Lua ecosystem over the years, can someone talk about the community's feelings towards that divergence? The OpenResty docs basically state it's not worth the effort to support anything but Lua 5.1, which at this point is 5 years old and no longer updated. From someone on the outside that makes me hesitant to spend much effort investing in the ecosystem. Are the libraries fragmented across different versions too? Are there really no plans for an upgrade path, or does everyone just expect to use 5.1 forever?

alexforster 9y ago
I believe this is because LuaJIT is 5.1-only.
anonymoushn 9y ago
People expect to use luajit forever.
scythe 9y ago
The reason is that the _ENV feature added in 5.2 would significantly slow down LuaJIT if it were supported. It's possible that Luac and LuaJIT will re-converge when Lua 6.0 is released, but arguments about this between Mike Pall amd Roberto Ierusalimschy have been unproductive so far. Until then, LuaJIT compiles Lua 5.1 with support for a few 5.2 and 5.3 features, particularly goto.
- rweichler 9y ago
  You have any references to these arguments between the two gods?
  - akavel 9y ago
    Totally not a concrete link, sorry, but - in a video from one of Lua conferences, I've seen Roberto mention in some polite yet clear way that talks with Mike which they had had always come to a standstill on something - at least that's how I recall it. On the other hand, since 2015, Mike was looking to pass luajit development on to someone else - so with this, situation could possibly change in the end. But I'm not sure what's the current status of this search; I seem to recall CloudFlare was reported to be in talks, but I don't know how it all ended - or if it's still unresolved.
    - rweichler 9y ago
      dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdad isjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafi osjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs00 9dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sd jf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas0 9sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90 dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdad isjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafi osjdafs009dfsja9sdjf09fdas09sdf09j90
- pygy_ 9y ago
  Why would `_ENV` slow down LuaJIT? It only offers a subset of the `setfenv()` functionality of Lua 5.1 that's implemented in LuaJIT...
  - rweichler 9y ago
    It uses lexical scoping, so it probably would mess up traces.
    - pygy_ 9y ago
      Late reply, but so does setfenv: > function foo()return function()return a end end > =foo()() nil > a=5 > =foo()() 5 > setfenv(foo,{a=6}) > =foo()() 6
      - rweichler 9y ago
        Nah I'm talking about the _ENV variable itself being in lexical scope.
        rweichler 9y ago
        i have no idea what im talking about tho.
        pygy_ 9y ago
        Ooooh, maybe this is relevant: > function foo() >> local a = _ENV >> local _ENV = a >> return {a=function() _ENV = {r=6} end, b = function() return r end} >> end > r = 5 > x = foo() > x.b() > =x.b() 5 > return x.a() > return x.b() 6 > vs > function foo() return { a = function() return setfenv(2, {r = 6}) end, b = function() return r end } end > x = foo() > = x.a() bad argument #1 to '?' (invalid level) stack traceback: [builtin#11]: at 0x0101faf2a0 [C]: at 0x0101f4ea60 > function foo() function bar() setfenv(2, {x=6}) end bar() return function() return x end end > e = foo() > =e() 6 I hadn't thought of that...
OhSoHumble 9y ago
This is my problem as well. I just installed 5.3 on my system but it looks like nobody really supports 5.3. There really is no clear guidance on what to do - do I just not use the latest version of the language?
- spc476 9y ago
  If you really need to use LuaJIT, then you best stick with Lua 5.1. Otherwise, use Lua 5.3---it supports 64-bit integers (unlike Lua 5.1/5.2, which only use floating point) and if you are doing any parsing of binary data, string.pack() and string.unpack() are worth using (Lua 5.3). Yes, there are issues with some Lua modules not supporting Lua 5.3, but the major modules support it, and LuaRocks makes installing modules rather easy.
  - OhSoHumble 9y ago
    Well, in the context of this thread, MoonScript, Lapis, and OpenResty don't support 5.3.
leafo 9y ago
For many libraries, it's pretty easy to write code that works across all the versions. For many differences it's not too difficult to implement code for maximum compatibility: http://leafo.net/guides/setfenv-in-lua52-and-above.html http://leafo.net/guides/setfenv-in-lua52-and-above.html For me personally, the advantages of luajit currently outweigh the desire to upgrade to newer versions of the language. Regarding Lua 5.1 being old, I haven't really found it to be an issue.. Lua isn't like most scripting languages, it doesn't come with a huge standard library. It's effectively just the language and some primitives. So it ages quite well as is.
catwell 9y ago
There is divergence, it's been a known issue in the community for years. I already had that slide in my 2013 "state of the Lua ecosystem" talk: http://files.catwell.info/presentations/2013-11-lua-workshop-lua-ecosystem/?full#34 http://files.catwell.info/presentations/2013-11-lua-workshop... The views on the issue amongst the community are divided too. Personally, I have decided most of my new code won't support Lua versions older than 5.3. That means no LuaJIT. If I have to use OpenResty seriously again, I will fork and adapt it to support PUC Lua 5.3. In the meantime, I use Xavante and WSAPI for the little Web code I write in Lua.
akavel 9y ago
For people knowing Lua a bit longer, the "divergence" is nothing surprising, it's an explicit and very long standing design choice by Lua authors. Specifically, that's what allowed them to evolve Lua to the awesome language it is, by making breaking changes when they invented/converged on a notably better way to do something. Personally, I find it more appropriate to look at each new Lua version as a wholly new language, rather than a "new release of the same language". A new language, which "accidentally", as a bow to the user, is very, very similar to the "previous language" from the Lua family (to the point of usually being API and syntax compatible). Actually, the changes between 5.1, 5.2, 5.3 are super small and smooth compared to what was done between e.g. 4.x and 5.x, where language syntax was changed. Between 5.x versions, with some effort you can make your code portable, if you wish so. (I'd say that's what one would expect when seeing the major digit unchanged in a version string.) There are many libraries which take care to. I'm not 100% sure about this one (i.e. haven't checked), but from the top of my head, based on the author's reputation, I'd blindly say https://github.com/stevedonovan/Penlight https://github.com/stevedonovan/Penlight should be a nice example of a library portable between 5.x versions. The proliferation of the 5.1 version is sometimes semi-jokingly seen as a "curse of success" - that it became the first version to really nail it so well, that it spread so wildly, and the newer versions bring small enough changes, that some people find it hard to justify any effort at all to upgrade. But it's also perfectly OK: Lua 5.1 is a great language already, and can simply be seen as a done/completed work.

alexforster 9y ago

I believe this is because LuaJIT is 5.1-only.

anonymoushn 9y ago

People expect to use luajit forever.

scythe 9y ago

The reason is that the _ENV feature added in 5.2 would significantly slow down LuaJIT if it were supported. It's possible that Luac and LuaJIT will re-converge when Lua 6.0 is released, but arguments about this between Mike Pall amd Roberto Ierusalimschy have been unproductive so far. Until then, LuaJIT compiles Lua 5.1 with support for a few 5.2 and 5.3 features, particularly goto.

rweichler 9y ago
You have any references to these arguments between the two gods?
- akavel 9y ago
  Totally not a concrete link, sorry, but - in a video from one of Lua conferences, I've seen Roberto mention in some polite yet clear way that talks with Mike which they had had always come to a standstill on something - at least that's how I recall it. On the other hand, since 2015, Mike was looking to pass luajit development on to someone else - so with this, situation could possibly change in the end. But I'm not sure what's the current status of this search; I seem to recall CloudFlare was reported to be in talks, but I don't know how it all ended - or if it's still unresolved.
  - rweichler 9y ago
    dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdad isjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafi osjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs00 9dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sd jf09fdas09sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas0 9sdf09j90dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90 dfsjifdadisjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdad isjodjafiosjdafs009dfsja9sdjf09fdas09sdf09j90dfsjifdadisjodjafi osjdafs009dfsja9sdjf09fdas09sdf09j90
pygy_ 9y ago
Why would `_ENV` slow down LuaJIT? It only offers a subset of the `setfenv()` functionality of Lua 5.1 that's implemented in LuaJIT...
- rweichler 9y ago
  It uses lexical scoping, so it probably would mess up traces.
  - pygy_ 9y ago
    Late reply, but so does setfenv: > function foo()return function()return a end end > =foo()() nil > a=5 > =foo()() 5 > setfenv(foo,{a=6}) > =foo()() 6
    - rweichler 9y ago
      Nah I'm talking about the _ENV variable itself being in lexical scope.
      - rweichler 9y ago
        i have no idea what im talking about tho.
        pygy_ 9y ago
        Ooooh, maybe this is relevant: > function foo() >> local a = _ENV >> local _ENV = a >> return {a=function() _ENV = {r=6} end, b = function() return r end} >> end > r = 5 > x = foo() > x.b() > =x.b() 5 > return x.a() > return x.b() 6 > vs > function foo() return { a = function() return setfenv(2, {r = 6}) end, b = function() return r end } end > x = foo() > = x.a() bad argument #1 to '?' (invalid level) stack traceback: [builtin#11]: at 0x0101faf2a0 [C]: at 0x0101f4ea60 > function foo() function bar() setfenv(2, {x=6}) end bar() return function() return x end end > e = foo() > =e() 6 I hadn't thought of that...

OhSoHumble 9y ago

This is my problem as well. I just installed 5.3 on my system but it looks like nobody really supports 5.3. There really is no clear guidance on what to do - do I just not use the latest version of the language?

spc476 9y ago
If you really need to use LuaJIT, then you best stick with Lua 5.1. Otherwise, use Lua 5.3---it supports 64-bit integers (unlike Lua 5.1/5.2, which only use floating point) and if you are doing any parsing of binary data, string.pack() and string.unpack() are worth using (Lua 5.3). Yes, there are issues with some Lua modules not supporting Lua 5.3, but the major modules support it, and LuaRocks makes installing modules rather easy.
- OhSoHumble 9y ago
  Well, in the context of this thread, MoonScript, Lapis, and OpenResty don't support 5.3.

leafo 9y ago

For many libraries, it's pretty easy to write code that works across all the versions. For many differences it's not too difficult to implement code for maximum compatibility: http://leafo.net/guides/setfenv-in-lua52-and-above.html http://leafo.net/guides/setfenv-in-lua52-and-above.html For me personally, the advantages of luajit currently outweigh the desire to upgrade to newer versions of the language. Regarding Lua 5.1 being old, I haven't really found it to be an issue.. Lua isn't like most scripting languages, it doesn't come with a huge standard library. It's effectively just the language and some primitives. So it ages quite well as is.

catwell 9y ago

There is divergence, it's been a known issue in the community for years. I already had that slide in my 2013 "state of the Lua ecosystem" talk: http://files.catwell.info/presentations/2013-11-lua-workshop-lua-ecosystem/?full#34 http://files.catwell.info/presentations/2013-11-lua-workshop... The views on the issue amongst the community are divided too. Personally, I have decided most of my new code won't support Lua versions older than 5.3. That means no LuaJIT. If I have to use OpenResty seriously again, I will fork and adapt it to support PUC Lua 5.3. In the meantime, I use Xavante and WSAPI for the little Web code I write in Lua.

akavel 9y ago

For people knowing Lua a bit longer, the "divergence" is nothing surprising, it's an explicit and very long standing design choice by Lua authors. Specifically, that's what allowed them to evolve Lua to the awesome language it is, by making breaking changes when they invented/converged on a notably better way to do something. Personally, I find it more appropriate to look at each new Lua version as a wholly new language, rather than a "new release of the same language". A new language, which "accidentally", as a bow to the user, is very, very similar to the "previous language" from the Lua family (to the point of usually being API and syntax compatible). Actually, the changes between 5.1, 5.2, 5.3 are super small and smooth compared to what was done between e.g. 4.x and 5.x, where language syntax was changed. Between 5.x versions, with some effort you can make your code portable, if you wish so. (I'd say that's what one would expect when seeing the major digit unchanged in a version string.) There are many libraries which take care to. I'm not 100% sure about this one (i.e. haven't checked), but from the top of my head, based on the author's reputation, I'd blindly say https://github.com/stevedonovan/Penlight https://github.com/stevedonovan/Penlight should be a nice example of a library portable between 5.x versions. The proliferation of the 5.1 version is sometimes semi-jokingly seen as a "curse of success" - that it became the first version to really nail it so well, that it spread so wildly, and the newer versions bring small enough changes, that some people find it hard to justify any effort at all to upgrade. But it's also perfectly OK: Lua 5.1 is a great language already, and can simply be seen as a done/completed work.