[CyberDildonics]

Lua is smaller, more consistent, and much more flexible with integration since it just C.

Debugging is built into the language in a simple way.

_G gets a table of all global variables

debug.getlocal allows you get any and all variables at each stack frame at that point including name, value and type.

You can even use debug.sethook to have a callback after every function, line, or instruction.

On top of all that you have LuaJIT which not only runs ridiculously fast, but can deal with dynamically loaded files incredibly fast. It even has a direct foreign function interface and allows you to use shared libraries directly without writing any more C or recompiling them.

[samatman]

Your last paragraph is the essence of why I chose Lua for my own projects, especially the FFI, but unfortunately doesn't apply to all of Lua. The divergence between Lua and LuaJIT is certainly not a strength.

The 'stock' Lua interpreter is very fast, very small (good for cache retention) and all its C functions are reentrant, so no global interpreter lock: those apply to both flavors.

As the tiniest of nitpicks, `_G` is the default home of the global environment, but it's just a variable. The correct way to get the environment is `getfenv(1)` or just `_ENV`, depending on your flavor.

[lifthrasiir]

> Debugging is built into the language in a simple way.

Lua debugging interface notably lacks breakpoints. You can simulate breakpoints by per-line hooks but it's not performant. Many popular JS engines including V8 do support performant breakpoints by bytecode patching, and Lua do have multiple patches doing the same (well, a common theme) but none is official.