3 ms·

Wish there is newer LuaJIT to leverage the new Lua features, but then maybe those new features are not really that critical.

Touche 1y ago
I feel like the existence of LuaJIT made is seemed like standard Lua was slow, but that's far from the case.
- 01HNNWZ0MV43FF 1y ago
  I spent a few nights trying to implement a Lua interpreter myself and it was still like 10x slower than PUC Lua, even before adding a GC. I'm not sure how they do it, it looks like regular C code
ux266478 1y ago
LuaJIT is amazing. I find it insane there are no Schemes that are able to match it as a tiny, embeddable scripting language with a JITer. GNU Guile is an absolute gargantuan monster in comparison.
- 1313ed01 1y ago
  But you can use Fennel, that is a bit scheme-like if you squint a bit, and it transpiles to very nice Lua code in my experience.
kragen 1y ago
LuaJIT is in somewhat active development, with 40 commits so far this year, although these are mostly bug fixes (some for bugs introduced by LLVM). The main new feature, if you can call it that, is "suport for Apple hardened runtime."
- 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 ago
    You 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 ago
      Except 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 ago
        Those 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 ago
      They 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 ago
        That 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 ago
cycomachead 1y ago
Agree, especially because it'd be nice for projects that use LuaJIT if you could swap the versions as needed.

Touche 1y ago

I feel like the existence of LuaJIT made is seemed like standard Lua was slow, but that's far from the case.

01HNNWZ0MV43FF 1y ago
I spent a few nights trying to implement a Lua interpreter myself and it was still like 10x slower than PUC Lua, even before adding a GC. I'm not sure how they do it, it looks like regular C code

ux266478 1y ago

LuaJIT is amazing. I find it insane there are no Schemes that are able to match it as a tiny, embeddable scripting language with a JITer. GNU Guile is an absolute gargantuan monster in comparison.

1313ed01 1y ago
But you can use Fennel, that is a bit scheme-like if you squint a bit, and it transpiles to very nice Lua code in my experience.

kragen 1y ago

LuaJIT is in somewhat active development, with 40 commits so far this year, although these are mostly bug fixes (some for bugs introduced by LLVM). The main new feature, if you can call it that, is "suport for Apple hardened runtime."

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 ago
  You 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 ago
    Except 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 ago
      Those 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 ago
    They 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 ago
      That 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 ago

cycomachead 1y ago

Agree, especially because it'd be nice for projects that use LuaJIT if you could swap the versions as needed.