I love commentary on LuaJIT, it's like a discussion of the subtleties of an acient game whose practitioners understand and enjoy, and everyone else ignores.
My experience with LuaJIT has similarly been love, not much hate though. My lack of hate stems from the fact that I don't actually use it in production. I've used it as a learning and teaching tool for the past 4 or 5 years.
What I've learned:
Co-routines combined with traditional async IO can make for some very fast IO bound programs.
JIT based FFI for interop is the cats meow
The guts of operating systems can be easily explained using such a simple language.
I went as far as creating a collaborative 3D modeling program (ala OpenSCAD) using LuaJIT.
I've created an entire Windows API wrapper (TINN).
I've explored the guts of Linux (using ljsyscall), and done exploration of various bits and pieces (lj2procfs).
I've been able to explore and play with any manner of API from dozens of OpenSource projects and otherwise, simply because LuaJIT (and specifically the FFI) make it possible to quickly wrap them up in such a way that exploration with script is easy.
I never worry about the death of LuaJIT, just like I very rarely look at the guts of my machine that's been running since 2009. The various parts may no longer be supported, but somehow my machines manages to continue to operate. Eventually I'll build another one and move on.
With recent changes to TypeScript, and the emergence of the Chakra engine, I might be tempted to make JavaScript my new thing, but they lack FFI, which I really love. I wish there were a solution for that.
Go has co/goroutines, which I really like, but I don't think their C interop story is particularly compelling, and not quite a scripty thing, which I find to be fairly useful.
I was originally driven to LuaJIT because PUC Lua had a flaw in their OpenGL binding, and it just wasn't robust enough for my needs. I find no value in their current versions, because FFI seems to be the most valuable thing to me I guess.
So, since it's a play thing for me, I find no other language as compelling or useful, for my needs. Some day, I'll use one of the language tool kits to convert my most interesting Lua code to another language, hopefully one with a good FFI. Until then, I'll keep using it.
And, if you've been around the industry long enough, you realize one language won't do it all for all time. I've long since given up on Objective-C (from NeXT days), I no longer write 6502 assembly (although still very popular apparently). I dove into C++ in the past couple of years, and came out with hives! Rust and Go are on the horizon, and who knows what's after that.
My perception of LuaJIT is that it's Mike Pall's creation (and what a creation at that!). He stepped down a while ago[1] and since then, at least to me, not much seem to have happened with LuaJIT. CloudFlare was in talks of project governance [2], and Cisco has pushed some MIPS support, but I havn't heard much else. There was a beta release in march this year for 2.1, but that's it.
The fork between PUC Lua and LuaJIT mentioned in the article is a major point of concern. For good and bad, PUC Lua is not known for backward compatibility. PUC Lua is at 5.3 and LuaJIT targets 5.1. There have been some breaking changes since then.
Without a strong community built around LuaJIT, or a corporate backer investing resources in it, I fear that it will die out eventually. I would be hesitant to implement something that uses LuaJIT with the project looking the way it does to me. I would love to be proven wrong though.
We still would like to hire someone to work on LuaJIT. We've found it very, very hard to find anyone suitable. There are few people who understand LuaJIT internals and few who want to get into it.
If there is someone reading this who wants to work on LuaJIT full time and thinks they have relevant background then please contact me.
Out of curiosity – would you have gotten much better value for money if you had donated more to Luajit whilst Mike was still at the helm?
My uninformed outsider's impression is that Mike Pall wasn't really widely successful at getting funding for the work he wanted to do on Luajit (e.g. new GC) – despite being probably the world's foremost JIT for dynamic languages expert[1] and the mileage that many extremely wealthy companies seem to have gotten out of luajit (e.g. I understand it plays a pretty important role in your firewall logic, and probably not one that would be easily replaced with some other technology).
I don't mean to single Cloudflare out for criticism, I'm aware that you have in fact funded Mike's work in the past. And maybe there is absolutely no relationship between Mike moving on and funding for luajit.
But since you replied here, I'd be genuinely interested to hear your perspective on this:
To me it appears that apparently even single-developer open source projects which directly affect the bottomline of large companies can struggle to make enough money to continue their work. Why is this?
[1] Seeing how he essentially single handedly wrote a JIT that seems superior in many respects to what the likes of Google have managed to achieve with Javascript after many lifetimes' worth of top developer effort.
I also worked on a JS2Lua transpiler, which is called exactly the same btw, for a university assignment (https://github.com/Etiene/js2lua) , but it's trash and I never really finished it until it incorporated all native JS functions and was actually usable. I have so many ideas that could use this. This is awesome. Thank you so much!
From the outside the message I am receiving is "hurry up and wait for a new maintainer to emerge from closed-door discussions between Mike, CloudFlare, and unspecified other parties." However, this has been the situation for over a year now, and presumably there have already been fruitless discussions with all of the obvious candidates. (Reading between the lines I suspect that the job description was "Mike Pall 2.0" and the qualified candidates were simply too expensive, but that is speculation.)
So what next for LuaJIT users? Keep waiting? Create a fork? Whine on Hacker News?
Personally I don't think we need a "Mike Pall 2.0." What we need is mere-mortal active maintainers who can review, merge, and maintain extensions developed by the community. This work could conceivably be spread between many hands -- if some of those hands would have a commit bit. I think it unfortunate that excellent work like Thomas Fransham's intrinsics implementation are stuck in limbo because there is nobody available to review and commit them.
End rant. I say this as a lover of LuaJIT and somebody who is using it for the long haul and thus very interested in its ongoing development.
No. He works at Google, and during 2015 he temporarily provided support to internal LuaJIT users there and made many contributions in the process, but working on LuaJIT is not his job. (The world world be a better place if it were!)
And for companies not named FaceBook, you probably have about 0 chance of hiring him away from Google where engineers who are really good at building jits are prized ($$$). I am an acquaintance of a very senior, very very good jvm engineer who was offered a ludicrous salary by G.
I would love to go through the internals of LuaJIT, learn all the necessary things and take over it. This is like my favorite project on earth. Unfortunately I just graduated and don't have the necessary background yet. Since I live in Germany I was almost thinking in just going over to Mike Pall on my next vacations and be like "teach me master" xD
Just one (more) encouraging note: The maintenance challenge that LuaJIT faces is actually kind of trivial compared with other projects like the extremely successful evolution of Spice Lisp to CMU Common Lisp to SBCL over a period of 30 years.
I am sure that project seemed like a corpse after Rob McLauchlan moved on in the 90s leaving behind a compiler much more complex than LuaJIT. However, dozens of open source heroes have picked up that project and moved it forward. Kudos to them :). Could be that we in the LuaJIT user community need to take a leaf from their book.
SBCL is enormous compared to LuaJIT, true. But most of SBCL is written in Common Lisp which is extremely easy to understand (statically and at runtime). It's also not a JIT compiler (in the deterministic sense).
LuaJIT source is terribly, terribly, terribly-written C code with minimal (and opaque) documentation that doesn't really facilitate human understanding. In that regard, LuaJIT __completely fails__ one of the maxims from SICP (code should be written primarily for humans to understand).
I therefore propose that this be one of the first issues addressed. The LuaJIT codebase needs to be refactored and extensively documented in such a manner as to facilitate rapid understanding by 3rd parties.
Agreed. LuaJIT is a lovely piece of code and very rewarding to read.
The situation is fantastically luxurious compared with CMCUL where the new maintainers needed to acquire a dusty old DEC Alpha to run a non-reproducible binary image with which to write a cross-compiler to x86...
That's where SBCL came from?! Wow, they really did a great job with it. I've no idea how they manage to compile a dynamically-typed language so efficiently.
I got the impression during my deep dive that it was elegantly designed and written code that solved problems that were a good two levels above my current experience. I don't think it's the place to go if you want to understand how Lua works or how JITs work. If you have a good working knowledge of those (I'm getting there) then you will be able to appreciate the codebase more.
One should not need good working experience of how Lua works or how JITs work in order to rapidly achieve a basic understanding of the codebase.
I am being downvoted because people can't look past personal likes/dislikes and are conditioned to look uncritically at software that they like/depend on.
Yet the obvious point I'm making here has nothing to do with the quality of LuaJIT as a tool that can solve problems. There are lots of examples of powerful, high-quality software that sits on an atrocious, impossible-to-understand codebase (e.g. pretty much anything by fabrice bellard, which ironically enough, some even consider as _good_ C) and while LuaJIT may not be at that level, it's not currently _good enough_.
I think we need to move past personality-worship and start striving for quality where it matters. Read this thread and you'll find numerous posts referring to Mike Pall as an alien/god-of-coding and so on. This is not at all helpful.
A software project that is positioned as something with staying power and a base for others to build on should be judged more on its ability to attract and maintain a community around it rather than its creator/profit that it generates/other superficial attributes. It is for this reason that a well-documented codebase that facilitates understanding is of _paramount importance_.
No. You DO need a good understanding of a computer language and of JIT compilers to understand the code base for any just-in-time compiler for that computer language.
LuaJIT is not a toy compiler from a textbook. There's a lot of inherent complexity in a production compiler that employs advanced optimizations and needs to work on various CPU architectures and operating systems. This reflects in the code.
Good points. Perhaps Luajit does need to be refactored into something more understandable to attract more people if it's going to survive in the long term. The major problem that I see is that we need another Mike Pall but with the added ability of writing code comprehensible by mere mortals.
I'm not sure you can refactor away the complexity of LuaJIT. It will always end up somewhere as a complete jit'ing compiler with no external dependencies just is inherently a complex beast. What might make sense it to have a more accessible documentation on how LuaJIT works. There are blog posts, mailing list posts and source code comments that probably give an almost complete picture, but there is not central place to find it all.
Yet another encouraging note: PostgreSQL is another wildly successful project that was originally developed by some geniuses in Berkeley and then taken over by a community of mere mortals. The core developers seem to view their role as being humble maintainers who try to carry the torch and keep the project moving forward and solving problems without screwing it up too much along the way.
LuaJIT is used for NeoVim tests and will be used in the future for writing extensions (in addition to VimScript). The NeoVim developers are planning to implement VimScript itself on top of LuaJIT. This is a bit sad considering the article and your comment. I wish they had picked PUC Lua, but can understand the reason why they went with LuaJIT instead.
Neovim will support PUC Lua 5.1 for both user scripts as well as internal lua logic. The external lua-client[1] supports luajit and PUC lua and the CI[2] runs PUC lua on every PR and commit.
The Neovim patch[3] to add built-in lua scripting will support both luajit and PUC lua.
Probably just because its faster than PUC Lua, enables FFI calls w/ less overhead, easy to interface with the existing C code? They are aiming at reimplementing the current C VimScript runtime (suffering from code rot and filled with preprocessor declarations for dead platforms) in Lua w/o degrading performance too much.
See the updated FAQ[1]. We are punting on the VimL-to-Lua translator. We think it will be more valuable to instead ship Lua as a first-class alternative to VimL.
> (suffering from code rot and filled with preprocessor declarations for dead platforms) in Lua w/o degrading performance too much
My love hate relationship is entirely with the language itself. It's incredibly useful as a game scripting language and is extremely easy to bind native functionality to, but man, the language itself rivals JavaScript for quirks.
1-based indexing is just a silly departure from decades of ingrained thinking, dictionaries masquerade as lists but can unintentionally become dictionaries if you mistakenly put a non-numeric key in them, and the only inheritance is prototype-based "classes" that are implemented via gross metatable hacking. Library support is also weak.
I will give it credit though for a robust coroutine implementation.
> 1-based indexing is just a silly departure from decades of ingrained thinking
This on only true for (not too old) programmers.
- Older programmers, taught pre-C, may remember that most languages were typically 1-based (Fortran, Pascal, Algol, Smalltalk...).
- Scientists usually use 1-based notation. I have avoided countless off-by-one by implementing papers in Lua. Matlab is also 1-based, probably because it is a language for mathematicians and scientists.
- In general, non-programmer tend to count from 1 and not 0.
> the only inheritance is prototype-based "classes" that are implemented via gross metatable hacking
If you need to you can implement non-prototypal object models, with metatables or with closures if you don't like them. My recommended object library is https://github.com/kikito/middleclass for people who want to write ojbect-oriented code (I usually don't).
> dictionaries masquerade as lists but can unintentionally become dictionaries if you mistakenly put a non-numeric key in them
I agree with this one, mostly. I would appreciate a purely sequential data structure ("list").
Looks like you got some down votes but I entirely agree. It isn't as bad as JavaScript, but turning typos into nil rather than raising an exception or having a compile time error is also annoying, in addition to the other things you mentioned.
I really wanted to like it for the small and simple implementation, but the language isn't pleasant IMO.
I have to agree here, however this is mostly not an issue if you use luacheck, assertions and unit tests.
Still, stronger typing would help, and this is why several people are working on adding gradual typing to Lua. The main initiative is probably https://github.com/andremm/typedlua
I've used luajit. It's unsupported software. If it works, great. If not, you're screwed. The original Lua may be ten times slower than luajit, but anyone can understand and debug it. That's worth something.
It's a shame luajit never created a community beyond its creator. FFI sure was nice.
> It's unsupported software. If it works, great. If not, you're screwed.
Not entirely sure how you got to that conclusion. Afaik there are no know bugs. All issues on https://github.com/LuaJIT/LuaJIT/issues are related to adding further optimizations or otherwise improve LuaJIT. In the last year bugs have been fixed almost instantly after they have been posted to the LuaJIT mailing list. So while I'm still a bit sad that Mike is on his way out, I wouldn't call LuaJIT unsupported. It's still a great choice.
In the last year bugs have been fixed almost instantly
That's good to hear. Perhaps LuaJIT isn't "unsupported", but it does seem to be "in maintenance mode".
I would love to see, not just bug fixes to LuaJIT, but ongoing improvements. Unfortunately with Mike having stepped down, and there being no successor, nobody is making these improvements and nobody is driving the project forward.
For example, will the new garbage collector [1] ever be implemented? Will LuaJIT remain stuck at version 5.1 while PUC Lua continues to add new features?
Mike Pall may not be maintaining Luajit any longer, but he still plays some sort of role preserving his legacy - shutting down genuine problems as wontfix. Here's one example:
If one heads over to GitHub to check some recently closed issues and recent commits one will discover that there are people who can understand and debug LuaJIT issues.
LuaJIT is not magic, it's a software. Very neat and tightly written but it's still just a bunch of C/assembly/Lua code.
Written by one human, and thus other humans can understand it too.
In theory you're right. But it's dense terse code with very little documentation. Some people can fix obvious problems around the edges, but no one would tackle a serious refactoring, porting to more recent version of Lua or adding a new feature.
As appealing as LuaJIT was and is, I could never bring myself to write much code for it. Even setting aside the possibility of Mike Pall giving up on the project (which turned out to be correct) the lack of a community around the language meant there would be difficulty getting questions answered and few third party LuaJIT packages. Bugs in particular were a major concern: if Mike Pall didn't find my bug report important, I'd be out of luck.
And as interesting as it is to have a small scripting language be able to run code so quickly, there are new languages that deliver the same benefits. Nothing really stands out about LuaJIT to make me feel it is a language I should use.
Bug reports with a reproducible test cases are often fixed and merged within hours. The craft, capability, and concern of Mike Pall has been amazing, even after he stepped down as maintainer.
My feelings are opposite. LuaJIT is here and now, and I won't wait for yet another community-driven python-or-rubylike that will [never] become its weak competitor.
Lua 5.1 itself is Scheme with regular syntax traded for macros, and one doesn't simply drop another language in for replacement.
The benefits I was referring to are being able to write fast, correct code easily. Other languages that allow one to do that include D, Go, Clojure, and Scala. If you want a scripting language, you're stuck with LuaJIT for now, but at least to me that's not an important distinction for anything I'd want to do with LuaJIT.
LuaJIT comes with warnings like "Callbacks are slow" and "The following operations are currently not compiled and may exhibit suboptimal performance, especially when used in inner loops:" which pushes it further down the list for me.
The vast majority of the time, swapping out Lua PUC with LuaJIT will result in code functioning the same but at least a little faster; often much faster. It's a pretty stable project.
The Haxe language targets Lua now [1], and some recent commits I've made enabled 5.1/LuaJIT support. Haxe syntax is significantly different than Lua syntax, but it's closer to ECMAscript, and most likely more familiar to the folks here. If the language syntax quirks are a barrier towards targeting LuaJIT, then check out Haxe.
I love LuaJIT, but what it needs right now is some sort of Lua5.3 compatibility. Despite being an excellent piece of tech I think this current state causes some damage to the Lua community because often developers will write code in a Lua5.1-style so it is compatible with both PUC-Lua and LuaJIT interpreters. This has made the adoption to newer Lua versions more difficult.
For me one of the big problems I have with luajit is using it in 64bit applications. luajit internals need to exist within the first 4gb of memory, and in some situations this can be a PITA to properly satisfy. There are solutions, but none I feel too comfortable with using especially cross-platform.
Given luajit development seems to be stalled, I don't have much confidence this will ever be fixed.
Try building (the `v2.1` branch of) LuaJIT with `CFLAGS=-DLUAJIT_ENABLE_GC64`. This flag is a relatively recent addition [1], and didn't have JIT support on x64 until really very recently [2], but it should free you from the 4gb limitation.
Looking at your PR for it (https://github.com/LuaJIT/LuaJIT/pull/149) it sounds as if there are a few issues remaining, but I'm not enough of an expert to know how problematic they are in practice. Do you think that this feature is stable enough for production use?
>Beyond the purist ideal of understanding the whole stack, this has practical implications. When you find a bug in LuaJIT, understanding it and fixing it is terribly complicated.
Well, how often people fix bugs in the compiler they use (and haven't written themselves)? Doesn't seem as much a "practical" consideration as the author says...
>Another issue is that PUC Lua and LuaJIT are diverging. LuaJIT implements Lua 5.1. Lua 5.2 code can be made to work as long as it does not use _ENV, but code that leverages the new features in Lua 5.3 is not supported at all
Well, not as much diverging as in "going to different directions" as that LuaJIT implements an older version. Isn't it supposed to eventually catch up?
Well, I have hit three different bugs in five years using LuaJIT, two of which I was the first to report. You cannot consider it as stable as, say, GCC.
Regarding your second point: Mike Pall had no intention to catch up completely. I don't know how much that has changed under CloudFlare leadership.
Thanks, I'd expect it to have some bugs (it's a much newer project than GCC, and even Python or Perl have lots of open bugs), but was missing the second information that Mike gave up on it. Last time I checked (a few years ago) it was still going forward.
The problem is that LuaJIT is an engine without a transmission or steering or braking system (this is a tortured analogy). It makes sense for PUC-Lua to have no standard library and focus on embeddability. It does not make sense for LuaJIT to do the same thing. LuaJIT's use case looks more like Torch -- scientific computing where a lot of stuff is written in C but you still need speed for the free-form parts and your target users are in a hurry -- and you need standard libraries for that. LuaJIT can compete with Go and C# on a speed basis, but not a usability basis.
Yeah, the actual compiler could use a maintainer, but who looks at LuaJIT and thinks "clearly, the weak point is the compiler!"?
Does anyone know what percentage of LuaJIT bugs are in the interpreter? You can still get a large speedup with it while avoiding the most complex code.
Edit: Also what's this about "a machine that does not support LuaJIT" that's apparently x86-based?
Not sure about the machine linked in the article, but sometimes the operating system might prevent you from marking heap allocated pages as executable.
However, in that case you are only prevented from using the JIT compiler and should still be able to take advantage of the high-speed interpreter included.
I wrote that article, just found out it was on the front page of HN today.
The machine linked in the article can not even run the unmodified interpreter (or at least it could not at the time) because its CPU does not support the CMOV instruction.
Regarding the bugs: I do think most of them are in the JIT and not the interpreter. Even using a lower optimization level that the default fixes a lot of them.
What's the processor in the Lima? The website has no technical information on it whatsoever (even under the 'Tech Specs' sections). Genuinely curious; I thought all x86 processors made these days supported CMOV.
I'm thoroughly bemused as to why they picked it --- unless you're aiming at some sort of binary compatibility, and given that it won't run Windows I have no idea what it might be compatible with, surely one of the ARM or MIPS stable would be more appropriate for this kind of device?
...over here, in this cardboard box, I have an old SheevaPlug: a 1.2GHz Marvell ARMv5 in a plug-sized box with some flash, an SD card interface, ethernet, and some USB ports, which appears to be pretty much the same device. (Of course, it's the software that's the interesting bit.)
I can confirm, using it for many years (already can't remember exact moment we went to lj).
Interpreter part 'just works'.
Also can't understand all drama about low support. We have a rocket with two modes: turboreactive, which just works, and sub-lightspeed mode where, well, strange things may happen. All those complaints about debugging of relativity shadow the fact that all other dynamic languages are conventional single-mode subsonic aircrafts.
I wonder what programs he was writing with Lua in Minix3 if he even was using them together? He mentions the stuff he wrote for work, and the hobby stuff later in Lua on Linux.
I also used Minix to learn about OSs back in 1991 by installing Minix 1.5 on my Amiga. Sad to say after spending an all-nighter getting it working, I didn't really dive in the way I had intended much after that. Tanenbaum's book was a real eye-opener for me. The source code and a textbook. I haven't seen much like it today. Still, I learned a lot about computers in general doing this, and would recreate the experience in my second dual-boot system, a Mac PowerPC running MkLinux in 1997!
There's something to be said for reading source code, and recompiling small OSs even if you just touch upon it. XV6 was re-written, and the source is < 10K LOC [1]. The course book is about 100 pages and the link also includes the source code in PDF to follow along.
I am also thinking on installing Minix3 on my dedicated linux notebook, but I am afraid I might botch it because my current system is UEFI/SB=off. I think you can only use BIOS/MBR with Minix3, although somebody has posted how to load it from a LiveUSB with Qemu, which you ditch after the install.
Ravi is interesting and well known in the Lua community, but it is far from the performance of LuaJIT. I don't think a LLVM-based JIT compiler will reach that level of performance anytime soon.
Its buggy too. Really needs someone to spend some time on it fixing the bugs, but there clearly is not the demand. Actually I am more interested in a maintainable static bindings generator.
As someone who doesn't know Lua and after reading this article, can it properly be said that a scripting language is fast if you write most of your time sensitive code in C? Why not just C?
It really depends on your use case. I write all my tight loop code in LuaJIT itself, rather than calling out to C. Lots of people use LuaJIT as the glue to highly optimized long lived and proven C code libraries.
The case for doing the glue in Lua is the fact that script is arguably easier to prototype in. So, depends on your particular application space. C can be a lot more error prone, at least when it comes to memory management, but this is a general argument for garbage collected vs not.
It is significantly quicker to write code in a higher level language, since the primitives and libraries do more per line of code. The cost is that it doesn't run as fast. But consider these two scenarios:
1 It takes 2 hours to write the code, and 1 hour for it to run.
2 It takes 2 days to write the code, and 1 minute for it to run
Note that "write the code" includes the actual writing, as well as debugging, testing etc. The first scenario is the most immediately productive. But the more you have to run the code, the more the second scenario applies.
Which is why you combine the approaches. Write the parts that aren't performance sensitive quickly in your high level language, and take longer on the performance parts in C. That works better than exclusively approach 1 or 2.
Thanks, I think you make a good case for using a language like Lua or Python with an excellent C interface. In some sense, writing everything in C could be a case of premature optimization.
Another benefit of Lua/Python is that it is considerably easier to write testing and debugging versus C. They support introspection and similar techniques. A very typical example is something I did a while back.
I wrote the processing in Python first. The core was 10 lines of code and took about 5 minutes to run on a unit of data. It took about an hour to write, and was correct.
It then took two days to rewrite in C and was 400 lines of code, executing in a second or so. Much of the time was finding and fixing minor bugs. But having the "correct" Python code made it very easy to feed the same test data to both implementations and verify the output. Writing test code in C would have taken even longer than just the algorithm!
Since someone mentioned it, how slower is PUC Lua in respect to LuaJIT? Compromisingly slower? Are there metrics out there or is it a relatively subjective feeling?
Though luajit has gotten even more optimisations since that was done.
That said, I rarely find my code's performance is the bottleneck, and don't benefit from luajit. The guys that do are doing scientific computing (e.g. torch) or high performance networking (e.g. snabb)
I've been involved in a project where we used LuaJIT. At some point we discovered that a bug in our build process was making it pick up PUC Lua (from the system-installed packages) rather than LuaJIT (from the build process itself).
This went under the radar for a while even though we had tons of traffic. Turns out PUC Lua is pretty fast on its own.
PUC lua is probably the fastest traditional scripting language. LuaJIT is much faster, in particular if you are interfacing with C, as the ffi has zero overhead, while the traditional Lua API is relatively slow. Also the performance is noticeable if you are doing a lot of work in the language too, generally as fast as C code for many use cases if you tune the code.
> PUC lua is probably the fastest traditional scripting language
That really depends what you are testing for. For string ops is not the fastest. For recursive Fibonacci (inefficient) LuaJIT is faster than D and Lua is faster than Perl.
There is a factor of ~5x between the slowest and fastest of these interpreters. LuaJIT with the JIT enabled is ~10x faster than even its own interpreter.
Wow, I'm not a Rubyist, so I had no idea about this. You all not only developed a faster, compliant interpreter, but Matz actually replaced MRI with an interpreter developed by a third-party as the reference Ruby interpreter? Huge props to him and the Ruby community for that.
Unfortunately, as a Pythonista (although one whose paid work is mostly in JS these days), I can't imagine that happening in the Python community (not to our credit). Too much ego wrapped up in CPython.
My experience with LuaJIT has similarly been love, not much hate though. My lack of hate stems from the fact that I don't actually use it in production. I've used it as a learning and teaching tool for the past 4 or 5 years.
What I've learned: Co-routines combined with traditional async IO can make for some very fast IO bound programs.
JIT based FFI for interop is the cats meow
The guts of operating systems can be easily explained using such a simple language.
I went as far as creating a collaborative 3D modeling program (ala OpenSCAD) using LuaJIT.
I've created an entire Windows API wrapper (TINN).
I've explored the guts of Linux (using ljsyscall), and done exploration of various bits and pieces (lj2procfs).
I've been able to explore and play with any manner of API from dozens of OpenSource projects and otherwise, simply because LuaJIT (and specifically the FFI) make it possible to quickly wrap them up in such a way that exploration with script is easy.
I never worry about the death of LuaJIT, just like I very rarely look at the guts of my machine that's been running since 2009. The various parts may no longer be supported, but somehow my machines manages to continue to operate. Eventually I'll build another one and move on.
With recent changes to TypeScript, and the emergence of the Chakra engine, I might be tempted to make JavaScript my new thing, but they lack FFI, which I really love. I wish there were a solution for that.
Go has co/goroutines, which I really like, but I don't think their C interop story is particularly compelling, and not quite a scripty thing, which I find to be fairly useful.
I was originally driven to LuaJIT because PUC Lua had a flaw in their OpenGL binding, and it just wasn't robust enough for my needs. I find no value in their current versions, because FFI seems to be the most valuable thing to me I guess.
So, since it's a play thing for me, I find no other language as compelling or useful, for my needs. Some day, I'll use one of the language tool kits to convert my most interesting Lua code to another language, hopefully one with a good FFI. Until then, I'll keep using it.
And, if you've been around the industry long enough, you realize one language won't do it all for all time. I've long since given up on Objective-C (from NeXT days), I no longer write 6502 assembly (although still very popular apparently). I dove into C++ in the past couple of years, and came out with hives! Rust and Go are on the horizon, and who knows what's after that.