Also, adding support for risc-v is good news, well done!
Also, adding support for risc-v is good news, well done!
Here are some numbers:
Lines of code: OpenJDK HotSpot (1.4M), LuaJIT: (92k)
Binary size: OpenJDK HotSpot server/libjvm.so (24MB), LuaJIT: (576KB)
Time to run "Hello, World": OpenJDK HotSpot (64ms), LuaJIT (3ms) (the JVM has improved here, it used to take hundreds of milliseconds)
For me personally, LuaJIT's small size and low overheads set a new standard for what I expect from JIT compiled runtimes.
I also find its small code base makes it approachable to learn from. I won't say that reading the code is easy, but I at least have confidence that whenever I have a question about fast interpreters or JIT compiling techniques, I can find the relevant part of the LuaJIT code and study it. Larger code bases can feel so sprawling that it's hard to ever find the snippet of code that will answer a question.
I think nowadays though, the landscape has changed quite a bit since when luajit was at its peak of popularity.
a) Lua is not necessarily the language one would always choose for scripting, in the first place. There's lots and lots of scripting languages to choose from these days. (It's also increasingly common nowadays for indie gamedev to happen entirely within a game editor, like Unity or Unreal, which provide their own scripting systems. That fact alone has killed a lot of interest in lua.)
b) If you do want to use lua, the features of the official implementation have progressed a lot since v5.1 (which luajit is pinned to), and its performance has improved over the years.
c) There are other competing lua and lua-adjacent implementations to consider as well, like OpenResty's luajit2 or Roblox's Luau.
You don’t really need these features cause Luas 5.x are mostly rehashes of the ideas rather than successive versions.
The team should have frozen it at 5.1, backport everything useful (yield across * basically) from 5.2 and call it done, only fixing bugs and tuning performance. That’s essentially what LuaJIT did/does.
Instead the “upstream” has 4 versions of the same thing with ecosystem and codebases fragmented as a UK flag, for no good reason. LuaJIT fixes that by being awesome, but lives under the shadow of n+1 stereotype, despite being a true engineering project rather than a chain of experiments. Tbh I’m glad I left Lua world many years ago.
As of motivation, I guess the best source is their mailing list around release dates. It was hot every time. Idk if anyone blogged about it, maybe just ask there.
for scripting I feel the new lua versions are great, still small, flexible and more powerful
It sounds so strange to me. Great in what? _ENV is the same setfenv() just in the other hand. Yielding across meta and C is nice, but should have been done in 5.1.6 regardless. __{pairs,ipairs} was just dancing around the same old tree as well. GC and interpreter improvements were independent of 5.x flavor and could be backported. Integers are pointless, sorry for the pun. 5.(n+1) may seem “more powerful”, but only because authors of Lua consciously leave 5.(n) undercooked. It’s adhd-rewrite-based development.
other than games, lua is very important to embedded systems
If you mean nodemcu, it stuck in 5.1 too. Everyone who did anything practical stuck in it, because they had shit to maintain. It’s very hard to explain to an innocent user why they have to periodically rewrite their scripts and bump fragile deps for this new “elle yu aeh” thing.
That being said, I use Lua on an architecture that LuaJIT doesn't support anyway – 68k.
---
[0]: https://love2d.org
[1]: https://lovr.org
Performance, size and compatibility. It's essentially a drop-in replacement for the stock Lua 5.1 implementation, with the same small size but with much higher performance. About the only downside compared to stock Lua 5.1 is that it's less portable.
However, development of LuaJIT almost stopped ~10 years ago, and only seems to be picking up again recently. In terms of the language it hasn't kept up with all the changes in Lua 5.2, let alone 5.3 or 5.4. And in terms of implementation, its performance is still impressive but no longer best-in-class compared to other dynamic-language JITs (e.g. for JavaScript).
LuaJIT's speed is very impressive, but the optimizations it can use are limited by its desire to remain lightweight.
It's understandable that JavaScript implementations, which don't have that restriction, can use different techniques and work out faster overall.
Sorry, you've lost me. What doesn't get used?