LuaJIT bucks the trend of slow-warmup JITs. It is extremely quick to compile and load, and its interpreter is very fast -- faster than the JIT-compiled code from LuaJIT v1 IIRC, and certainly faster than the interpreter of Lua.

It wasn't until LuaJIT that I realized that JIT didn't inherently have to be these slow lumbering beasts that take hundreds of milliseconds just to wake from their slumber.

Yet I've witnessed Lua 5.1 launching faster than luajit for some of my use cases.

My point still stands though. Don't just use LuaJIT thinking it will magically make things faster in all cases. If you are embedding, LuaJIT is a no-brainer. If you are using a stand-alone interpreter, measure if you care about reality.

> If you are embedding, LuaJIT is a no-brainer. If you are using a stand-alone interpreter, measure if you care about reality.

This seems backwards. Lua is easier to embed and luajit is just as easy to install standalone and has zero downsides.

> zero downsides

I just said that I have measured it being slower in at least some use cases.

JIT gains better when already compiled paths run repeatedly. Most long running programs embedding Lua will choose luajit for this reason.

I don't care what people use, the point is that JIT compilation isn't magic that makes everything faster. The way to know is measure.

I'll tell you what, it's a hell of a lot faster starting up than Bash is, but I hear you.

You know what the new interesting hotness might be? Getting the LLM to write wasm (via wat, its textual analog), and running that with https://wazero.io/ , which is astonishingly fast (although still not as fast as luajit for some reason, despite being lower-level), but also gaining multiplatform without recompile in the process