Hacker News Reader

Comment by bsaul | Hacker News Reader

i’ve always read about how the lua jit was a technolical marvel ( without understanding why but that’s another topic). If that’s the case, then how come it isnt’t maintained anymore ?

View on HN

At the time I'm writing this, the latest commit in https://github.com/LuaJIT/LuaJIT was 26 minutes ago. There has also been a constant stream of commits over the last months (I didn't check further), but no frantic activity. Almost all commits in the moonjit history also seem to be be cherry-picks of these LuaJIT commits.

So calling LuaJIT unmaintained, and saying that moonjit "continues development" both seem a bit exaggerated to me.

The v2.1 branch of moonjit specifically aims to remain "luajit-like" in the sense that it is the explicit goal to make sure we don't add incompatible features and we definitely don't make it so that if Mike Pall decides to continue development after a year (which he appears to have done, although one can never be sure given his record over the past few years), we can easily enough merge patches.

The master branch is where moonjit development is more active with people adding 5.2 and 5.3 features and new architectures too. It is in a way a different direction from luajit (since Mike specifically stated that he intends to remain incompatible with stock Lua because his dialect is better) and hence may not necessary converge with luajit if it ever actually comes back to life.

The last time Mike Paul pushed anything is almost a year ago until two weeks ago based on the two RSS feeds I use. The Git commit dates could be unreliable from either cherry-pick shenanigans or him just not bothering to push the changes until two weeks ago.

Maybe compare your feeds with:

https://github.com/LuaJIT/LuaJIT/commits/v2.1

I see quite regular commits there?

The last release was a beta from May 2017.

Calling LuaJIT unmaintained isn't exactly true. It's still getting commits, however the author has stopped trying to keep it up to date with the mainline Lua updates. Lua has a history of not caring too much about backwards comparability, so the LuaJIT devs have decided to stay with Lua 5.1, even though 5.1 is nearly 10 years old, and 5.4 is on the way soon.

Uh? Being a 'technical marvel' has little relationship with making money and without money developers may choose to do something else whenever they want..

IIRC there's a comment from Mike Pall (maybe it was here, can't bother to search it for now) where he stated very clearly that there was always enough money on the luajit table. So no financial reasons, he just wanted to do something else (and he didn't like the new lua features so much, pain to implement and all that stuff, so maybe that's the real reason...).

Features in PUC-Rio Lua after Lua 5.2 or so are mostly all terrible, with the possible exception of <toclose> (a bad version of golang's defer). So I respect the choice not to add those features. There was still lots of work to do to improve the GC and such though.

What about integers and bitops in 5.3? That seems like a big deal

Bitops are in LuaJit

Lua 5.3 integers are 64 bits long by default, and that makes a real difference.

That's trivial to implement as a C function though, so no real need to add it as a language feature

Reply on news.ycombinator.com