My spontaneous reaction is “meh, 5.3”. And yes, that’s the latest version, but as long as the upstream Lua is so slow compared to LuaJIT, the LuaJIT version is the important one for me and a lot of other people.
Considering the application to a boot loader, I think in this case it’s understandable to prefer the slower, simpler interpreter - remember this environment is so simple that it doesn’t attempt to support floating point.
LuaJIT doesn’t seem to be maintained anymore. The last official release is 2.1.0-beta3 from 2017-05. And only this beta supports newer architectures like aarch64. There are several forks of LuaJIT now but.. OS distributions aren’t exactly happy about random forks, are they?
Plus, there’s no need for JIT performance when what you’re replacing is shell, an embedded Forth, VimScript…
I always prefer upstream Lua because I don’t do high-performance things and I wish LuaJIT didn’t divide the ecosystem by sticking to an old language version >_<
I see what you’re saying and I handwaved all LuaJIT forks away and should’ve said “LuaJIT etc. (Raptor looks good so far) - and I know as much as the next person that languages shouldn’t just stagnate but are evolving. But as someone who has only ever used Lua either “embedded” as a scripting language or deployed in an appliance-like setting (it won’t be touched or upgraded except security fixes) I really don’t need any progression and want stability. Lua on its own is a nice language, but if it’s so slow it’s not helping me. For (and this probably unfair to the Lua team) since LuaJIT was on the market, that’s what I wanted to use. It’s more upstream Lua’s fault for not being as fast, not LuaJIT’s fault for being unmaintained. And yes, this is close to a fork situation, but for me it’s clear on which side I am.
My spontaneous reaction is “meh, 5.3”. And yes, that’s the latest version, but as long as the upstream Lua is so slow compared to LuaJIT, the LuaJIT version is the important one for me and a lot of other people.
Considering the application to a boot loader, I think in this case it’s understandable to prefer the slower, simpler interpreter - remember this environment is so simple that it doesn’t attempt to support floating point.
Looks like this is intended to scipt some things for the bootloader. Just curious what you’re particular application of luajit is?
LuaJIT doesn’t seem to be maintained anymore. The last official release is 2.1.0-beta3 from 2017-05. And only this beta supports newer architectures like aarch64. There are several forks of LuaJIT now but.. OS distributions aren’t exactly happy about random forks, are they?
Plus, there’s no need for JIT performance when what you’re replacing is shell, an embedded Forth, VimScript…
I always prefer upstream Lua because I don’t do high-performance things and I wish LuaJIT didn’t divide the ecosystem by sticking to an old language version >_<
I see what you’re saying and I handwaved all LuaJIT forks away and should’ve said “LuaJIT etc. (Raptor looks good so far) - and I know as much as the next person that languages shouldn’t just stagnate but are evolving. But as someone who has only ever used Lua either “embedded” as a scripting language or deployed in an appliance-like setting (it won’t be touched or upgraded except security fixes) I really don’t need any progression and want stability. Lua on its own is a nice language, but if it’s so slow it’s not helping me. For (and this probably unfair to the Lua team) since LuaJIT was on the market, that’s what I wanted to use. It’s more upstream Lua’s fault for not being as fast, not LuaJIT’s fault for being unmaintained. And yes, this is close to a fork situation, but for me it’s clear on which side I am.