Inbound transmission

As of 1/2/10, the dominant scripting languages on the internetz are mainly ECMAScript AKA JavaScript (henceforth referred to as JS) and PHP. Now you might say my opinion is biased in favour of Lua, it is, but I’m basing this on logic. I shall exclude PHP from this discussion/flamewar because honestly there are no good solutions for the niche belonging to PHP, namely serverside page scripting.
(Update: Ian, see below in comments, has pointed out Lua Server Pages which aims to be a replacement for PHP.)

Let’s start off with usability. Usability is 99.999% of the time more important than performance. Usability can make or break a language, much how immersion can make or break a game.

If a language isn’t usable people aren’t going to use it. (If you can avoid it that is.) Same thing applies to APIs, if you pull off all the marketing propaganda you’ll expose DirectX for what it really is: A clone of OpenGL that took almost a decade before being actually usable, and is still not as powerful in many respects. (I’m not going to go into that right now, but if you really really want to, go here.)

Now if you’ve ever tried working with JS you’d find that it’s like Java but bastardized, like Java is a bastardized version of C++, which in turn is a bastardized version of C. Now you could do a lot worse than JS, but honestly if you like doing things like ‘var arr = new Array(string)’ or whatever, there’s something wrong with you.

Now what if we used Lua instead? All this mishmash of built in objects and data structures goes away, you’re left with tables (and userdata). Okay, so far so good. Now, you can customize your behaviour of objects easily by overriding keys in the per-object table. (I’m assuming you’ve associated a table with each userdata object by way of setenv, note that this is Lua 5.1) Alright, great! What else? Your arrays are now also hash tables, and you can store any key with any value you want, and that is a wonderful feature of Lua that I really like.

Now you’d have to expose all those objects to Lua, sandbox it so it doesn’t suck up all the CPU if something goes haywire, implement all the required APIs, debug the system, etc… You’re already doing this for JS, so there’s no reason you can’t do this in Lua. Lua is a great glue language.

Overall Lua is just more usable/easier than JS, you can’t deny it. (Although I’m sure some people would try, probably citing something along the lines of existing codebases all being in JS, but that’s outside the scope of this post.)

With usability cleared out, let’s take a look at the all important performance aspect. On first appraisal Lua flunks out pretty badly. (Except for calculating π, Lua is very good at calculating π, which is slightly odd how much it differs from the other tests.)

Ouch, but not too bad, it could be worse. Let’s take a look at TraceMonkey:

Well, in both cases Lua flunked out performance wise, except for calculating π and memory use, both of which were far better than either JS implementation.
(Update: Okay, maybe not so much vs. TraceMonkey… Thanks for the mention Duncan!)
However, I’ve deliberately overlooked a key point.

Lua is interpreted bytecode. V8 is directly complied to native machine code, and TraceMonkey is a tracing JIT. Let’s even the fields shall we? Let’s take a look at LuaJIT2, here’s a chart that was made from the first beta of LuaJIT2:

SciMark          composite  |
small                score  |  FFT     SOR      MC    SPARSE    LU
----------------------------+---------------------------------------
GCC 4.3.2            906.1  |  739.1   909.0   190.4  1057.0  1635.1
JVM 1.6 Server       876.3  |  573.8  1185.5   297.7   579.2  1745.4
JVM 1.6 Client       579.6  |  424.8   895.8   122.8   595.5   859.0
----------------------------+---------------------------------------
LuaJIT 2.0.0-beta1   580.4  |  427.4  1025.0   223.7   303.4   922.5
LuaJIT 1.1.5          96.7  |   72.0   166.1    37.1    91.8   116.5
Lua 5.1.4             16.5  |   11.0    27.4     7.6    16.9    19.5

As you can see, LuaJIT2 blows its younger brothers, Lua and LuaJIT1, right out of the water, going so far as barely running past Java (Client) who’s been working really really really hard at trying to be fast for the last decade or so. As you can see, LuaJIT2 was even faster than obsessively optimized C in one of the tests (MC). That should give you an idea.

But I digress, here are the results when you shove LuaJIT2 into the gladiator arena with V8 and TraceMonkey:

Impressive isn’t it?

Overall, Lua is smaller, faster, simpler, and far more elegant. And to give a sense of scale, Lua is developed by three people, and LuaJIT1/LuaJIT2 by one. Now think of the armies of programmers at Google and Mozilla’s disposition.

PS: As a side note, LuaJIT2′s x64 port was mostly financed by Google. I wonder why… Google would never take the technologies of LuaJIT2 and use them to try and hack up V8′s performance because they can’t.
(Update: Maybe I’m just being too cynical, see Ian’s link to Google’s blog post on LuaJIT2.)