It's hyper-optimized, small, and can be multithreaded or multiplexed trivially, but that's true of lua as well. The array thing gives it a leg up in speed as well, as does 0-indexing. Finally, its gc algorithm doesn't have cpu bursts (it's not "stop the world"). I don't know of Lua has this feature, but it makes the language ideal for real-time applications. Like games.
You can run multiple interpreters, embedded in the same application, in separate threads: multiplexing, as you have multiple instances, as opposed to multithreading, where you have a single instance.
> It should give you a Lua environment that allows you to effortlessly run tens of thousands of Lua processes in parallel, leveraging the famed microprocesses implementation of the Erlang VM. The empty Luerl State footprint will be yet smaller than the C Lua State footprint.
It really speaks more to the runtime than the language. There's nothing fundamentally anti-parallel about lua, but even just concurrent GC is difficult to execute well. Look at how big of a deal Go's recent low latency claims are.
I thought it could, but I think I might have been wrong... Nope, just coroutines. Sorry for being wrong. However, as it is small and embeddable, it's trivial to spin up multiple instances of the interpreter. But Lua and TCL are just as good at that.
