Comment by roxolotl
1 year ago
Lua is a much cooler and more useful language than I think it, publicly, gets credit for. I know it’s widely used in many industries but so many times I’ve read an article like this and thought that it could be even more widely useful.
I’m currently writing a just for me static site generator in Fennel and it’s sad to see just how many powerful packages are abandoned. A lot of it is because they are mostly complete and part of why I like it is lack of churn but a last update on 18 months ago is very different from 10 years.
I want to host knitting patterns with my site generator and techniques like this make it super easy to build a little pattern dsl. It’s stuff like that which makes me wish it was more widespread.
You can learn about various opinions in this thread: https://news.ycombinator.com/item?id=42517102
so many times I’ve read an article like this and thought that it could be even more widely useful
Lua is not widely used because it doesn’t exist. Lua {5..1-4,JIT} do exist, but these are different languages between which you and others can easily port code sometimes. It’s sort of cool in a moment, but if (when) you live through a couple of versions, that just gets old. It’s not immediately visible, so you’ll see reviews from 5 stars to zero at all times.
Actually, Lua exists all over the place, in all kinds of amazing applications - but because Lua is an embeddable VM, you mostly don't know about it that much. Its not exposed because - when you use Lua professionally, you tend to bury it deep in the problem it solves for you.
> Lua is a much cooler and more useful language than I think it, publicly, gets credit for.
I think it’s gets about the right amount of credit. It isn’t obscure by any means, openresty is used quite a bit in odd places, so many games have used it. PyTorch (well what became it) was originally written in it (it was just torch but basically LuaTorch)
It doesn’t get more adoption because its warts and limitations really start to show once pushed into more into a “real” language. It doesn’t have the browser monopoly. It’s also quite slow, and LuaJIT doesn’t always magically fix that.
Lua without JIT is one of the fastest interpreted languages. In fact it might just be the fastest. LuaJIT is also one of the most advanced JIT compilers out there, frequently beating V8 and others.
There are very valid complaints about Lua. It lacks useful quality of life features. Some of its design decisions grate on users coming from other languages. Its standard library is barebones verging on anemic, and its ecosystem of libraries does not make up for it.
But after using Lua in many places for well over a decade, I’ve gotta say, this is the first time I’ve heard someone claim it’s slow. Even without JIT, just interpreter to interpreter, it’s consistently 5-10x faster than similar languages like Python or Ruby. Maybe you’re comparing it to AOT systems languages like C and C++? That’s obviously not fair. But if you put LuaJIT head to head with AOT systems languages you’ll find it’s within an order of magnitude, just like all the other high quality JITs.
Vanilla Lua traditionally doesn’t show any substantial difference to python or ruby. You’re probably talking about LuaJIT in interpreter mode (jit off).
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> consistently 5-10x faster than similar languages like Python or Ruby
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Python and Ruby have had steady increments of improvement over the last decade.
> Lua without JIT is one of the fastest interpreted languages.
Maybe I should say it is "still slow". Of course you can find examples of 5-10x over python performance (not that this is saying much), this is not the norm. There's just no way, PUC-Lua is still fundamentally dynamic hash tables for lookup with a big switch statement, there's a certain limit to how fast this can go. Let's just say there are plenty of game devs that have found that Lua quickly becomes too slow for the task it has been pressed into which then becomes an exercise of exporting more and more stuff to C++ or whatever. There is Luau of course, which sort of proves this point.
These interlanguage comparisons are mostly meaningless anyway. Python may be slow, but you do the heavy lifting in other ways and that ecosystem is huge. Since the Lua ecosystem is small though you are usually on your own. LuaJIT FFI is sorta cool, but wrapping can still be a PITA.
> Maybe you’re comparing it to AOT systems languages like C and C++? That’s obviously not fair.
Or C#/.NET/Java/Kotlin/JVM. Which you can often use as part of a plugin system.
> this is the first time I’ve heard someone claim it’s slow.
Quite ironic to say this, because I'm pretty sure this is why Mike Pall created LuaJIT in the first place. For example http://lua-users.org/lists/lua-l/2011-02/msg00742.html (but there are many other great in depth essays in the archive)
> LuaJIT is also one of the most advanced JIT compilers out there, frequently beating V8 and others.
No it's not these days. LuaJIT is awesome and may have been alien technology in 2005 but has a lot of missing functionality compared to the most advanced JIT implementations.
There were of course many examples of LuaJIT beating V8 on particular microbenchmarks through the years, and many of these are rehashed from over a decade ago and are outdated. I wouldn't say this means it "frequently" beats V8, especially in a practical sense.
Anyone that has much experience with LuaJIT and has stared at a few traces is aware of "NYI" - there is a ton of stuff that is not implemented in the JIT and means fallback to the interpreter, including even pedestrian uses of closures: https://github.com/tarantool/tarantool/wiki/LuaJIT-Not-Yet-I.... There is a ton of stuff that current V8 does to optimize real world larger applications that LuaJIT JIT will bail on.
LuaJIT does well when you write code in a particular style that exploits its strengths. It's not quite as amazing for general purpose use.
Elsewhere you suggest that a GC rewrite is actively being developed, but LuaJIT development has slowed tremendously, the mailing list is not very active and I wouldn't be holding my breath for anything major (this new GC has been talked about for well over a decade).
> LuaJIT doesn’t always magically fix that.
Not to mention there are some significant performance issues on aarch64. Love2D, a popular game framework, opted to not use JIT on macOS for this reason.
https://github.com/LuaJIT/LuaJIT/issues/285
This is strictly about how much memory LuaJIT can address on that platform. There’s no “significant performance issues”. If your workload fits inside 2 GiB (IIRC) it will be fast. LuaJIT is a world class JIT.
For a long time a new garbage collector has been an open issue for LuaJIT, which would fix this particular issue, and make the language even faster. Last I checked this was actively being worked on.
1 reply →