Hacker News Reader

Comment by _dcwr | Hacker News Reader

It's 5.1 compatible plus some nice-to-haves from 5.2: http://luajit.org/extensions.html

I wouldn't call it 'not in development' and even if, then 5.1 is a fine version of Lua and LuaJIT is battle tested very well and rock solid still. Changes in Lua 5.2 and 5.3 are breaking (and some are deep, like the ints, bit ops, function environments) but most of 'usual' code is compatible between 5.1, 5.2 and 5.3.

I learned Lua 5.2 and then went back to 5.1 when 5.3 came out because I didn't like the int stuff in 5.3 and didn't want to use an obsolete version (5.2) with no upsides (5.1 has the upside of being compatible with LuaJIT).

View on HN

If someone has mixed feelings from what FRex said here, but is not aware of what Lua world consists of, let me explain. Js will be mentioned, so reader can have a base level of understanding what happens and how good/bad it is. It is not js criticism.

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?

Is this just Python 3 vs 2, with PyPy refusing to update to 3?

Pypy supports Python 3...

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.

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.

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.

To those who downvoted FRex's comment:

Do you care to elaborate? I don't see anything wrong with it.

(And it's definitely more insightful than the slightly older sibling comment, which apparently has not been downvoted.)

Maybe someone fat-fingered it?

No, it had more than one downvote when I upvoted it, i.e. stayed grey after upvote. Moreover, I just saw it being black, then grey, then black. So it still receives a mix of downvotes and upvotes. Very strange.

I tried to upvote and it's still grey. There's obviously something wrong in the information, but those who know better aren't taking the time to impart that to us.

If you or someone can't come and point out that 'obviously wrong something' then don't say that just because a comment got downvoted for some bizarre reason. That same comment now has 11 points. I hope it didn't now become 'obviously right' to you just because of the point count. The fact this (going into 'grey' or 'black' with 0 retort or correction given by anyone) even happened is just stupid to me.

I believe nothing I said is wrong and anyone is welcome to prove me wrong. I also answered the original questions/doubts clearly (Is LuaJIT stuck on 5.1 and no longer in development - no and no and there is nothing wrong with 5.1 itself). The only downside could be how brief I was but I gave plenty of keywords ('ints', 'bit ops', 'function environments') for an astute reader to google or look up in the documentation of Lua (which is a Ctrl + F friendly one pager plain HTML with minimal styling and no JS, I have it as a single .html file with inline PNG and css on my desktop to use offline).

This stealthy downvote drama is why I use HN passively, logging in only to do a fire and forget comment. I've just avoided seeing this entire downvote debacle unfold in real time during my normal browsing (and thus avoided wondering what's going on or if I were providing people wrong information or something else wrong on my part, since it's not like any downvoter told us why they did it) because of that habit.

Reply on news.ycombinator.com