Is this just Python 3 vs 2, with PyPy refusing to update to 3?
An important part of this is that Lua is generally embedded into larger programs. This is pretty much the #1 production-grade use case of the language. So when a new version of Lua is released, no one is actually expected to update their old versions. Rather, they use the new version in future projects. This allows the language designers to improve the language in ways that are backwards incompatible (imagine if JS could do this; the `let` keyword wouldn't even exist because you could just fix the default scoping).
So Lua 5.3 has a lot of breaking changes without a clear upgrade path. LuaJIT simply isn't going to support this, because its users generally use it more like a normal scripting language like Python and expect more stability.
It may be simply a game of words, but if taken literally, then the point is still missed. There is no “update”. These three could be named 5.s, 5.e and 5.i respectively. For setfenv, _ENV and integer experiments. No “justs”, please, this poisons Lua image in a wrong way.
Python 3 was meant to solve a problem (among other features ofc). 5.1, 5.2 and 5.3 are engineerng experiments, there is no “problem” that LJ has in respect to these two, nor the other way round.
Pypy supports Python 3...
Re:Neovim v0.2.1 released
by RussianCow on Wednesday November 08, 2017 @11:11AM
(#15653799)
I think the parent meant that as a hypothetical: The Lua situation would be like the Python 2/3 situation if PyPy decided not to support Python 3.
First of all, original 5.1 was a complete language with few technical problems unsolved. These problems were hard and didn’t exist, say, in javascript, because it has no such primitives at all, not because 5.1 was bad. To name a few fundamental: yield across pcall, C-call, for-iteraror; specific metamethods for regular tables.
LuaJIT derived from 5.1 and then development went in parallel, never being stopped or unmaintained. Original Lua experimented with features in 5.2 and while it fixed and added few nice things, it used completely different env resolution (which also doesn’t exist in javascript). 5.2 was also improved in execution speed. LuaJIT specified that it will stick with original env scheme, and personally I find it more powerful than new one. All others features were backported from 5.2, so effectively LuaJIT is 5.2 with setfenv() still working, not some obsolete chunk that you may try to guess from semantic versioning, which doesn’t take place in Lua. Versions of Lua are NOT “semantic”.
5.3 introduced things that personally I find mad, and it diverged from 5.1/5.2, which were pretty compatible if written with care (not more incompatible than javascript is in different browsers; an order of magnitude less so). So, the future of 5.3 is somewhat unclear to me. It is still good language, thought, planned, experimenting, technical, non-crowd non-legacy driven. It will show what’s wrong and what’s right, as all Lua versions perfectly did.
To sum it up. If you’re going production, you can take any version of Lua, and it will be still more compatible and feature-rich than different versions of javascript. If you want all 5.1 design holes covered and incomparable execution speed, then you take LuaJIT in place of 5.1. If you want new environments (read what they are before you want), take 5.2. If you want to test new experiences and language design, take 5.3. But there is no superiority in any version, unless you’re taking one of these perks to extreme. These are different but similar languages with different strengths.
I know it’s all harder than just “5.1 < LJ < 5.2 < 5.3”, but what can you do?