I have kept looking for a replacement of Perl for several years. Now I have found it: Lua, although the decision is not made based on the language itself, but on its implementation LuaJIT.
LuaJIT is by far faster than all the other scripting languages and even comes close to the speed of Java with fewer lines of code and a smaller memory footprint. To further confirm the efficiency of LuaJIT, I implemented matrix multiplication in C, Lua, JavaScript and Perl. On my laptop, the C implementation multiplies two 1000×1000 matrices in 2.0 seconds (BTW, 1.4 sec if I use “float”; 0.9 if SSE is used; 26.8 sec without matrix transpose), LuaJIT-jit in 2.3 seconds, LuaJIT-interpreter in 24 sec, JavaScript in 40 sec with V8, Lua-5.1.4 in 64 sec and Perl in 283 sec. As a dynamically typing scripting language, LuaJIT achieves a speed comparable to C, which is simply amazing.
Not only that, LuaJIT fixes IMO a major weakness of Lua: the lack of native bit operations; the upcoming Foreign Function Interface (FFI) library, according to the LuaJIT roadmap 2011, will definitely make Lua one of the best scripting languages to bind dynamic libraries, even surpassing Python’s elegant ctypes library.
With the unparalleled efficiency and the addition of important features, LuaJIT makes Lua the best scripting language at present in my opinion. Mike Pall, the single developer of LuaJIT, commented in an interesting discussion that it is possible to implement a JIT compiler for Javascript, a language similar to Lua in many aspects, as efficient as LuaJIT. But Javascript is not a general-purpose programming language by design. Standardizing additional language features would take years. As to other scripting languages, my impression is their complexity is the major obstacle to the implementation of an efficient JIT compiler.
Probably more developers are concerned about the lack of standard libraries in Lua. Personally, I do not see why Lua cannot be a general-purpose scripting language. Probably the creators of Lua just did not intend to or have energy to implement a comprehensive standard library. I hope someone may organize a group of good programmers to develop such a library. Furthermore, with the upcoming FFI library in LuaJIT, we may be able to easily call library routines, which may solve the lack of library issue again with one man only.
LuaJIT is the future of all scripting languages. Even if LuaJIT were not adopted as widely as I wish it to be, I hope the advanced techniques and ideas developed in LuaJIT can be incorporated into other interpreters and JIT compilers.
Attractive Chaos 
“Not only that, LuaJIT fixes IMO a major weakness of Lua: the lack of native bit operations”
The next release (5.2) has bit operations.
I kind of wish you would have also thrown in the default interpreter time in there for a comparison of LuaJIT vs the default implementation. IMO it would reinforce the notion of just how fast LuaJIT is in comparison.
Anyways, I agree, Lua (and LuaJIT specifically) is a great language and implementation. As for a standard library, I much prefer the language proper to have a relatively small base library, and then supplemental libraries for various other tasks. It would be nice if there were a bit more comprehensive community library for common tasks that is often included in other languages standard libraries. (Or even more community libraries for that fact.) Really though, I think (hope) it will only get better as more people realize the elegance and simplicity that Lua offers 🙂
@Harley
I have added the time with the official Lua interpreter 5.1.4 (64 seconds) and with “luajit -joff” (24 seconds).
As to a standard library, I also much prefer a small base like Lua/C. Nonetheless, I wish the developers/creators of Lua had time to maintain a standard library such that the coding quality is guaranteed, feedbacks are centralized and no one needs to frequently install separate modules.
To me, without a high-quality standard library, Lua can never be a general-purpose scripting language like Perl/Python/Ruby. My impression is the creators of Lua do not care about this. But it is sort of a pity that Lua cannot go that far given its simplicity and advances.
attractivechaos
I actually like the fact that if I need functionality not in the core then I have to use a addon module, rather than a kitchen sink distribution in which I would have to spend time removing/disabling anything not wanted.
What is it you would like to see in a “standard library”? For Windows there is the batteries included Lua For Windows http://code.google.com/p/luaforwindows/
I do not mind installing separate modules on my machines, but when I want to distribute my scripts, dependencies become a concern, especially for modules that bind to C libraries. FFI will alleviate the issue, but will still be a little awkward in comparison to Perl/Python/Ruby. I wish the Lua creators could release two packages, one is “lua-lite” which is the current package and the other is “lua-full” which include the standard library. This would satisfy users with different emphasis.
I did not know Lua for Windows (thanks!), but a collection of modules might not be what we want. With a collection, the API convention may vary, coding quality cannot be guaranteed, and modules are more likely to be outdated or not synchronized between developers and maintainers. With an official standard library, a lot of programmers will be happier. However, in that case, the Lua developers are obliged to maintain all kinds of modules, which definitely requires a well organized Lua community. It is not easy.
attractivechaos
Not to be funny but there was only one question in my reply yet you have not addressed it. 😦
What is it you would like to see in a “standard library”?
“I wish the Lua creators could release two packages, one is “lua-lite” which is the current package and the other is “lua-full” which include the standard library. This would satisfy users with different emphasis.”
I personally think that would be a big mistake. It would split the community, require a lot of work of the team and go against the very ethos of the Language. From my observations of this topic, which has been hashed out to death, the vast majority of people who say they require/want a standard library don’t actually use the Language.
I think a standard library should at least support threading, filesystem, socket, XML, getopt, compression, regex and doc generation, and better have GUI, graphics, protocols and more as in the standard Perl/Python library. Luaforwindows is quite complete, but it is not officially supported and is for windows only. It is has not been updated for half a year.
Initially I felt the same, that the stewards and developers of Lua were too focused on having a bare minimum API that could fit on embedded hardware etc, even to the extent that you can’t get the time in milliseconds in straight Lua (and thus, can’t generate good random numbers easily).
However, I’ve since discovered LuaRocks, which is pretty much like gem for Ruby or eggs for Python, serving as an installer and hosting service for popular Lua packages.
It still has a way to go before being really smooth and reliable (I had tremendous troubles getting it running properly with LuaJit in Windows… OS X was easier in that I don’t recall the process), but it’s something. Perhaps it’s worth browsing the Luarocks package list to see the range of projects that are available.
As for the chance of other dynamic languages to implement luajit’s techniques, there is a very interesting thread here http://lambda-the-ultimate.org/node/3851#comment-57700 .
There, you’ll see comments by Mike Pall as well as the mozilla javascript and pypy developers.
Sorry, the most interesting bit is this one: http://lambda-the-ultimate.org/node/3851#comment-57804
Although the whole thread is worth reading…
…forget it. I see it’s already mentioned in your post 🙂
@Oisín: Thanks for mentioning LuaRocks. I will have a look when I have time.
@Luis: Your links are more precise than mine. It is not easy to find relevant discussions in such a long thread. I keep your links. Thank you.
@attractivechaos Hey, I came across your blog from your programming language benchmarks. LuaJIT is certainly impressive (picked up a tweet from Mike Pall by way of Ryan Dahl).
As I’m sure you realize, Lua was designed for embedding, so it makes sense that it doesn’t come “batteries included” like Python. While I definitely can appreciate “batteries included”, some members of the Ruby community have been talking about going in the other direction: http://www.rubyinside.com/is-the-ruby-standard-library-a-ghetto-3966.html
What Ruby has is a really solid package manager with RubyGems and auxiliary tools like Bundler to support this possibility. Consider Rack vs WSGI, it was some time before Python 3.2 came out with WSGI updated for Unicode. Meanwhile, in the Ruby community can iterate on Rack independently of the core Ruby team. Another thing in the Ruby community is that we’re fairly standardized around MIT licensing and GIT DVCS.
For Lua, what we could aim for is something more like distributions, say if you want LÖVE for games or Kepler for Web Development, with some common libraries for either (Unicode, unit testing, etc.).
Maybe we just need some additional effort on LuaRocks and supporting tools/websites, things like http://ruby-toolbox.com/, etc.
A really consistent high quality standard library applicable to a wide range of tasks would be great. There is no reason to say such an effort couldn’t take place in the community. An effort akin to Zend Framework, though indeed a pretty huge undertaking to coordinate.
For linux, I’m hoping that lua + Gobject-introspection will catch on and become mature (Both lgob and lgi exist, both on gitorious). These meta-bindings suddenly allow access to the Gnome platform + more on equal footing with all other (dynamic or not) runtimes. This would be interesting to compare with for example GNOME’s current gnome-shell (implemented in javascript)
I tried Lua and had to drop it after a week, because it lacked a feature which I use all the time in other languages.
The one thing where Lua is very weak, is the absence of multithreading. In today’s world , multithreading is a must. Lua has something called coroutine, but it looks very tedious and very cumbersome to use when compared to the multithreading facilities offered by other language like java or Ruby.
Lua’s got plenty of multithreading capacity, in the form of Lanes, coroutines, Rings, LuaThread, concurrentLua, and a myriad other implementations ranging from pure Lua to Lua mixed with the c API.
Extending it to match your own expectations should be trivial. Something tells me that “had to drop it after a week” means “I couldn’t spend more than 2 days on learning the ins and outs of Lua, so I gave up.”
Don’t expect everything to be handed to you on a silver platter (even though Lua does a fair job of it.)
Why not create a Golden Full Stack web framework for Lua that will satisfy all the web developers with clean and clever API and stuff like cloud support Google App Engine support etc. Standard library could come in later …
Because that is the antithesis of the Lua philosophy. Massive, all-feautres-included, all-things-to-all-people bullshit like that can stay the fuck away from Lua, thanks.
Well that’s a load of purist nonsense. The point of Lua is that you can build your own tools, any way you like. Not that nobody should ever build tools with it.
If you want to keep your Lua small and “pure” then fine, do that, but don’t go demanding that everybody else do it and obey your religious (sorry, “philosophical”) beliefs to the letter. That’s just unpleasant douchery.
Lua is the niche-language. For embedded programming, for example, or lightweight scripting, bcz for strong scripting Python/Ruby/etc will be used.
I take it you’ve never actually used Lua then?
It’s actually a quite nice and powerful language with a simple and pleasant syntax. There’s no reason why large programs can’t or shouldn’t be built with it, except that there are less libraries available for it than in Python and Ruby, and less built-in functionality (for example, it does not seem possible to get the current time in milliseconds in Lua, without using C extensions like the socket library).
Both vanilla Lua and especially LuaJIT are also amazingly fast compared to implementations of Python and Ruby, although hopefully projects like Pypy and Rubinius will help to close this gap somewhat, because they are lovely languages too.
To write Lua off as a “niche” or “embedded only” language would be a mistake.
“Personally, I do not see why Lua cannot be a general-purpose scripting language. Probably the creators of Lua just did not intend to or have energy to implement a comprehensive standard library.”
…And the award for most retarded statement of the century goes to…..
How is it compared to MATLAB’s M for math calculations?
I really wish all these m0rons would stop asking for a standard library. Especially the comment that suggests a lua-lite and lua-full. If a standard library is optional — it’s then not “standard” at all is it, you f**king imbecile?
Sociopath much? Go away and calm down before you try the internet again.
and what about running luac vs luajit-jit ???
As I understand, luac improves loading speed, but not execution speed.
any good debugging environment out there working with LuaJIT?
does LuaEdit work with it?
unfortunately the luajit benchmark was removed from shootout, anyone has the most updated v8 vs luajit benchmark? v8 is currently the most impressive scripting language on shootout (speedwise), ruby is the other most impressive one – code #lines : used the least codes.
Those interested in debugging with LuaJIT may take a look at ZeroBrane Studio (http://studio.zerobrane.com/).