3 ms·
LuaJIT is also stuck at Lua 5.1 (by choice) while the latest is Lua 5.4, with 5.5 on the way.
by Rohansi 1y ago
LuaJIT is also stuck at Lua 5.1 (by choice) while the latest is Lua 5.4, with 5.5 on the way.
- kragen 1y agoYou say that as if Lua 5.3 and 5.4 were better than Lua 5.2 (which LuaJIT has support for most of the new features of) or 5.1, rather than merely newer. But programming languages don't decay like your teeth.
- flykespice 1y agoExcept they are? Lua 5.3 bitwise literals are a big improvement over the builtins bitand32, bitor.. the addition of integer type makes the language more suitable for embedded systems that don't have FPU.. Lua 5.4 added const attribute for local variables..
- kragen 1y agoThose are tradeoffs, and I'm not convinced they're good ones. Suitability for processors that are so small they don't have an FPU isn't relevant to LuaJIT in any case, but you've been able to compile Lua with integer numbers since 1.0.
- Rohansi 1y agoThey don't decay but it results in a split like Python 2 vs. 3 where some Lua code is not valid in applications using LuaJIT.
- kragen 1y agoThat happens with all Lua applications, because Lua has never aimed for backward compatibility from one version to the next, so applications basically never upgrade to a new version of Lua.
- Rohansi 1y agoNew applications using LuaJIT will continue to be on Lua 5.1. And applications that do upgrade their dependencies but use LuaJIT are going to be stuck on 5.1 maybe forever, too.
- kragen 1y agoYes, and there's nothing wrong with that. It doesn't result in the same degree of fragmentation in Lua as it did in the Python 2/3 split, because it's both socially accepted and usually technically easy to write code that works in both Lua 5.1 and Lua 5.4 and everything in between.