Lua's great. I recently used it to rewrite a small audio effect framework[1] based on an older project of mine in C[2]. To my astonishment, without any optimization efforts on my part, the LuaJIT version of one effect ran faster than the C version, while another more complicated effect (a filter) only took 2.01x as much time as C. And this was with simple, clean, mostly declarative code (read it on GitHub and see what you think).
One of the goals of this project was to compile effects code to JavaScript with Lua.js[3] and produce a demo that ran in the browser. There, unfortunately, I ran into a showstopper with a Lua.js bug[4] that breaks my approach to creating modules. Unlike LuaJIT and regular Lua, Lua.js is an experimental project and far less mature - though totally awesome. I might make another attempt to fix the problem myself at some point. With a more mature Lua.js, you could write fast Lua code and port it to nearly every environment.
I chose lua because of its built-in coroutines. For a simple mud server, blocking until the next line of input is ready works really well. Because it's not preemptive, you don't have to worry about locking. Because MUDs are so niche these days, you don't have to worry about the userbase scaling out of control.
Never did get around to writing a mudlib, though...
I'm curious to do some performance comparisons, can you perhaps say how one would build and run your code to replicate those benchmark results? (Especially but not only the one you say was faster in LuaJIT?)
In short, I ran C and Lua implementations of the same command, 6 times each, using the built-in "time" command in bash. Averaged the "user" time for each implementation and compared the results. As input, I used a 2m:38.040s long song, 44.1 KHz stereo, converted to a raw file with 32-bit float samples, and I redirected output to /dev/null.
For the first benchmark[1], which was faster for LuaJIT, I actually messed up: I compared the "real" time rather than the user CPU time. But as I recall, the "user" times bore the same relationship, and there was very little deviation among the six trials. If you don't trust me, feel free to do a more rigorous test!
It's worth mentioning that the effect for which LuaJIT beat C was a simple gain, so what was really being tested was a loop that multiplied a bunch of numbers by a (within the loop) constant. The second test in which Lua was a factor of two slower may be more representative.
To build the code, clone the graue/synth and graue/luasynth repos on GitHub. synth includes build instructions, while Luasynth merely requires you to install LuaJIT and run the script.
One of the goals of this project was to compile effects code to JavaScript with Lua.js[3] and produce a demo that ran in the browser. There, unfortunately, I ran into a showstopper with a Lua.js bug[4] that breaks my approach to creating modules. Unlike LuaJIT and regular Lua, Lua.js is an experimental project and far less mature - though totally awesome. I might make another attempt to fix the problem myself at some point. With a more mature Lua.js, you could write fast Lua code and port it to nearly every environment.
[1] https://github.com/graue/luasynth
[2] https://github.com/graue/synth
[3] https://github.com/mherkender/lua.js
[4] https://github.com/mherkender/lua.js/issues/13#issuecomment-...