The problem is that it isn't a good "starting place" for an app. Instead you write something in C/C++ and say "oh, I wish I had a dynamic language for this part" and then you add Lua on top. And this is part of why Lua is such a compelling language now - by being extension-focused it's been able to iterate the entire language many times over and make basic semantic changes without worrying about backwards-compatibility.
But if I start writing an app and want something Lua-like....it ends up being easier to start in Python. There are some good projects out there to address this but it's a question of maturity - as of right now Lua still doesn't really satisfy as a "batteries-included" platform.
This is a very good point - Lua seems to have improved quite a bit since (say) 4.0 - it's small enough that maintaining an in-house fork of on old version is an option, so the language designers can make major changes when it's a clear improvement.
As library maturity goes, there are some really good ones out there (such as LPEG and LuaSocket), but for some things the documentation is a bit thin. The situation is getting better, though.
This is exactly the problem, imo. Lua is a niche language because its benefits only apply to a certain niche, i.e., scripting glue on top of an extant system, because that's where the time investment makes sense.
Is Lua so much better that using it is worth losing the convenience of something like Rails or Django? Those things come all bundled up nicely with everything you need for a website. Is it worth the investment to go around and scrape all of these pieces together in Lua? Is Lua going to provide a benefit commensurate with the time you invest in piecing all of that together yourself, including the real possibility that you'll have to write much of the functionality yourself? Or is it simply cheaper and smarter to use Python or Ruby where the frameworks are already composed and widely tested and deployed from the get-go? There's your answer.
To the extent that one wants to increase adoption of a language in a certain niche (say, web programming), you need to at least attempt to make it basically competitive. However cool and fast Lua may be, for most people, it's not worth the investment to start from scratch on a framework when Python has Pylons, Django, Pinax, and Ruby has Rails, etc.
lua is not a one stop shop and will never be, which probably why it flys under the radar so much - you cant stamp a powered by lua logo on it.
Also, the idea reminds me of this: http://c2.com/cgi/wiki/wiki?AlternateHardAndSoftLayers
And there is a c/++ library for almost everything.
QScript, ChaiScript, and projects like boost.python and libperl++, play much better with your C++.
I've considered a number of these for my current app, especially QtScript, Lua and Squirrel, but eventually I settled on embedding a JVM, since it gives me access to a bunch of libraries and lets me use any JVM language (I'm personally using Clojure and Yeti, but users of my app could in theory use other languages).
I went. That's not what I found. For example:
In fact, while we're on the subject, here's an example of recommendations and praise of Lua on comp.lang.ruby (note: google groups displays it a bit out of order):
Really? I don't think so. If it's for Web or desktop stuff, sure. For other things, there are a lot of "it depends".
Seriously, outside the heavy gravity of Planet Rails, Ruby devs are pretty open about what you can reasonably do with Ruby.
One of the the reasons that it hasn't caught on the server side is that the server engineers are lazy (in the friendly way), and have it easy. If you have performance problems, you can just throw more hardware to it.
So Python is a decent choice, plus the lots of libraries/batteries included, make the life easy to lazy developers. Again, by lazy, I mean people that just want to use the stuff to create features, and not worry about fundamental stuff.
The fun stuff is usually in large dataset processing scaling, database scaling, etc. where a single box is not the bottleneck.
But for mobile dev., python is just too much of a pig. I think lua will win when these devs. start moving to the server side. Mobile / embeded devs have to re-invent the wheel often, and are just use to it, so they are less lazy by definition (they are more likeley to just create a framework from scratch, then just use things that are already there).
But the current trend is the opposite, as more server guys are moving to client/mobile. There is more growth in the client/mobile side, so there is not much cross pollination going on upstairs.
Smart devs. are either solving interesting problems below in the embeded world, or above in large scale datasets. The middle stack (your average crud app), is left with more average types.
Since it takes a brave soul to start with a great language, which unfortunately doesn't have all the libraries that some more mature languages do, Lua hasn't found that great of usage yet in the server side.
Perhaps it could happen when a generation of iPhone developers who have written games in Lua decide they want to do some server side development.
I have less hope that Lua will take off though. Appropriately, I'm giving a talk on Lua/Erlang integration at Erlang Factory in March, which will be on using Lua as you describe - for command and control of a larger Erlang system.
It's reasonably complete, but its development is being driven by another project (a distributed filesystem of sorts), and it's still changing too much. I hope to have it released in a month or two, but I'm also in the process of buying a house, and that's keeping me plenty busy.
Really, if you're building desktop software I couldn't recommend it highly enough.
Roberto is scheduled to speak about Lua at Stanford in the Stanford EE Computer Systems Colloquium from 4:15-5:30 in Gates B01. As is usual for the Colloquium, the talk will be webcast live and available for delayed viewing, on demand, over the web. Anyone who wants can attend live. See the Colloquium website for details: http://e380.stanford.edu.
People who works in the game industry and people who works in web technologies rarely collide with each other.
Perhaps the reason Lua isn't gaining ground in the web scene is because it's too exotic, however fair that might be. It has a foreign object model and a different syntax. Both of these combined might create the perception that it's difficult to learn.
I'm not sure though. For me, I've always been interested in Lua, but I've never picked it up because I never see any web apps made with it.
Spreading knowledge between game developers is easier, though. People move around between companies a lot, and your publisher's team of lawyers is less likely to be present at a conference talk than finding NDA violations by crawling the web.
That's obviously the case for games and their 3D / physics engines, but Lua is steadily gaining momentum in the embedded devices world, where CPUs are also pushed to the limits of their (lesser) capabilities.
Web developers have already put most of their high performance wizardry in their SQL engines, and already have standardized/comprehensive APIs to these databases; I don't think Lua would bring them much, and certainly not enough to compensate for the loss of Python's or Ruby's existing web-friendly libraries.
Of course, the same goes for any scripting language (I've worked with a proprietary script language at my last dev shop), but I like the fact that lua is light, minimalist, clear and a standard that others will know, but also very extensible. I'd definitely say the the small core and lack of huge external libraries is a good thing, when you're developing for fixed hardware like game consoles.
This probably rules it out for people who only know Python, Ruby, PHP, etc., which in turn limits exposure among web developers, who seem to have disproportionate presence on blogs.
I do quite a bit of work with Lua and never use it with C.
And although you're technically true, the lack of a library implementing reals as userdata let me guess that few people have found this approach practical. Unless I missed it?
I guess people just use the LNUM patch.
Never hear about Bink! video player either although I see it's used in every game I play.
Also, I hear about Lua quit a bit.
Lua's a pretty good language, though. It's completely replaced Python as my default language (much like Python replaced Perl years before), because, while it too has its surface annoyances, it makes a lot of other very intelligent trade-offs.
Likewise, Lua's rather spare standard library is because the language strictly* limits itself to the ANSI C standard. In exchange, though, it's portable to literally anything with an ANSI C compiler, including freaking Legos (http://www.hempeldesigngroup.com/lego/pbLua/). The whole thing fits in a 200ish KB library, too. Not bad for something as expressive as Scheme and Python.
* With the exception of dynamic linking, which can potentially provide everything else down the line.
Protip: Having kids is a great way to legitimise buying things like Mindstorms. eg, without kids - "I just spent $300 on Lego" "Wow, what a sad life you lead". with kids - "I just spent $300 on Lego" "Wow! What an awesome parent you are. My Dad never did anything like that for me"
It's still not a problem if your whole program is in one file, though. Since the global environment is just another table, you can set its metamethods to warn about any accidentally global vars. This is an example in PiL, and strict.lua is included in the standard Lua distribution. require "strict", problem solved.
The Lua designers know that unrestricted global-by-default vars cause a lot of pain in Awk, but defaulting to local scope for everything instead can make using closures awkward (as in Python), since it's difficult to know automatically where variables are local to. In the other languages you mention, C doesn't have proper lexical scoping, Scheme and Common Lisp have fully parenthesized syntax (and thus no scoping ambiguity), Python's closures are awkward, and Haskell (and ML) use let blocks and other explicit scope markers. This is a semantic issue in any language where you can nest blocks and the default is a series of statements, not individual statements (i.e., "begin" / "progn" is the default).
See also: http://lua-users.org/wiki/LocalByDefault
From Mark Hamburg's intro to _Lua Programming Gems_, pg. xii:
"...Large portions of Lightroom ended up getting written in Lua including the object-relational mapping layer for the database and the layout system for views. [...] As a result, we had an application that was smaller by far than some of its competitors, easy to change, largely cross-platform in its implementation, and suffered essentially no compile-link cycle. [...] Lua is both very expressive compared to most native languages and sufficiently efficient that you can let it do a lot more of the work than one might be tempted to do in other scripting languages."
The users are allowed to script in this dynamic(changing) enviroment. ROBLOX is a plastic brick based online lego game. The massive physics engine creates realistic explosions, and LUA lets you alter it, make things happen. LUA is a GREAT language.
Also, Lisp macros would be nice (didn't look at metalua)
And it comes with macro capabilities, plus syntax extension facilities to make them more user friendly.
They are just a bit unorthodoxal.
For learning Lua, Ierusalimschy's _Programming in Lua_ is the best book, by leaps and bounds. There are a couple other Lua books, but that one is succinct yet comprehensive, like K&R and Pike's Bell Labs stuff.
The Lua Users' Wiki (http://lua-users.org/wiki/) is also helpful, as is the mailing list.