I have trouble finding a use for Lua, even though I like it better as a language than most.
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.
> 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.
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.
>Lua still doesn't really satisfy as a "batteries-included" platform.
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.
you need to realize lua isnt targeted as a batteries included platform, its design philosophy is minimalist, not junk included but customize for your requirements. where lua absolutely excels is when paired with C (not C++) and not used as "scripting glue" but fully integrated and driving the system. it really appeals to minimalistic / keep it simple philosophy guys which isnt the web community.
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.
I think it's true you need to watch out for this 'gap' between a full blown, batteries-included language, and something really small. Tcl sort of fell into it when they grew the language and libraries to the point where it's less attractive as a small, embedded language, but never really got it together enough to ship it with all the goodies included, either, meaning you have to round up a bunch of external things to do much with it. It's not a 'happy medium'.
I couldn't agree more. Lua is arguably as nice a language as Python, and it has a nice embeddable implementation, but it doesn't have the libraries and documentation.
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).
Lua attracts a lot of devs with a pretty low-key, humble attitude. If you go to a Ruby mailing list and ask people "should I use Ruby for x?" the answer will mostly be a resounding "yes." On the Lua list, people will often tell you "that depends," will advocate for lots of other languages, or even tell you "no, I don't think so." I think that's in part because of Lua's history as an embedded/glue language: many programmers who work with Lua don't use it as their primary language, and so they don't have the same urge to hard-core advocacy and evangelism that many other languages' users have.
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):
You're right, I chose a lousy example. Much of my experience with Ruby revolves around Rails, so perhaps that colors my perspective a bit more than I sometimes realize.
Lua is used a lot, but usually as a command and control language. Meaning that it is always used together with another language/system, where performance matters, both for runtime and development time, and memory constrains..
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.
I think the explosion of node.js is actually evidence of what you're saying; the web guys who were scared of the server are taking their javascript skills there via node.js.
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.
FWIW, I'm working on something similar in Lua, which uses libevent for high performance on Unix but also has a pure Lua (based on LuaSocket.select) backend for portability. I haven't tested it on Windows yet, but I don't expect any issues with running it there, and I'm planning on supporting it as a platform (for developing convenience, not performance).
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.
If you're interested, learning Lua should would be pretty straightforward. It sounds like you're already proficient in Javascript, and they have quite a bit in common.
At my last company (that's still going, I've just sold out and moved on. . . ) I used Lua for the lion's share of our kiosk content distribution platform. It was perfect, especially considering how many times we had to dip down into C or C++ to get at devices. We built out a tiny host C program that dynamically loaded in modules and frameworks as needed on each kiosk. It was beautiful, FAST, and cross platform (XP/Linux/OS X). I'm back in the web world these days but I miss Lua quite a bit, it's a fantastic little language.
Really, if you're building desktop software I couldn't recommend it highly enough.
Roberto Ierusalimschy, PontifÃcia Universidade Católica do Rio de Janro, is the author of Lua and also author of several excellent books about Lua. Lua is a very nice language with a small footprint, powerful structure, and a fascinating and flexible object model.
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.
It's a shame that it's mostly being used for games. It's got incredible flexibility and power and even the mainline runtime (sans JIT) is surprisingly performant. More people should give it a try.
Python and Ruby largely continue the class-based object oriented model and are thus easy to pick up if you come from a C++/Java background. While JavaScript is prototype-based, and thus somewhat exotic, it at least maintains the syntactic heritage of C/C++, so it's not as scary as it otherwise might be for beginners. Plus most in the web development background have already known the language for years.
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.
I am a novice programmer, but have used Lua for some basic (second- or third-year college programming level) projects, and I found the transition from the very mainstream languages (Java/PHP/Python) extremely easy. That said, I was doing fairly straight-forward imperative programming, so perhaps I never delved deep enough to see the "foreign" parts of Lua. To me, Lua seemed as easy a language to learn as one could hope for.
I don't think it's so much that they rarely collide, it's more that the game industry is NDA-infested. Gaining a public profile as an employee for a developer working on a game for a publisher is a risk. People get fired for lesser things than talking about how Lua helped them in Project X.
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.
Lua shines at interfacing with C; it's useful when you've got a high-performance engine in C or C++, and want a friendly programming interface to control it.
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.
I work for a major worldwide game developer, and our project currently uses Lua for a lot of dynamic scripting and behaviour control (the rest of the game is in C++). I've been pushing for a higher usage of it, as it allows a lot more runtime iterating than with C++, where the compile+link+load times on a project this large are killer, whilst Lua can easily be hot reloaded.
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.
I think one of the reasons that Lua gets less attention (outside of certain niches, most notably the game industry) is that, to get the most out of it, you need experience with C or C++. The libraries available for standalone Lua are somewhat small compared to (say) Python, because in most cases you'd just use C libraries anyway. In exchange, though, you can leave each layer to focus on what it does best.
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.
You're right, but I think this is much less true now than it was a few years ago. With the libraries developed by the Kepler project (for example) you can do quite a bit of useful coding without ever touching C.
I like Lua as a language. I especially like how easy it is to embed it into another program. I'll be using Lua for scripting my current project. The only thing I really don't like about it is that it treats all numbers as double-precision floats. It can be compiled to use 32-bit ints instead, but I'd really like to have access to both, especially since floating point arithmetic is insanely slow on embedded processors without an FPU, but sometimes I really need it.
If the processor doesn't have an FPU, there's not much of an extra disadvantage to compiling with int32s and then making reals just another data structure, implemented in terms of ints, with a library to manipulate them.
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?
Dude, you can find a reason to write off every language in existence. Lisp has all those parens. Python has the whitespace. Perl...is Perl. Etc. Nothing's perfect.
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.
For example, indexing arrays from 1 is a consequence of ensuring that Lua would have a syntactic subset usable as a data description language by non-programmers. It's almost identical to Javascript's JSON in that regard, but has been used in production as such for well over a decade.
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.
I chuckled because it felt fresh, but it does come off as another kind of programmer-snark like better-known cliches about Lisp(parens), Python(whitespace), Java(overengineering), etc.
+1 for pbLua. I've used it for a few things and it's brilliant. Docs are pretty good too.
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"
Every once in a while, I used to think, "What about Lua? Wouldn't Lua be nice?" Then I would start reading the docs, and stop when I came to the "local" keyword. Ick. Variables are global by default, you have to explicitly label local bindings. If any scope is the default, it should be local scope. Accessing an uninitialized variable is also not an error. Chalk this up to personal taste, but this reminds me too much of bad experiences in bash scripting. The languages I prefer: Python, Haskell, C, Scheme, Common Lisp... never play so fast and loose with where your variables go.
While you're right that "global by default" is usually a problem, it isn't in Lua, because Lua also lets you restrict the global scope (with i.e. setfenv). Generally, the "global" scope you get by default is "global to the current module", i.e., publicly exported from a module.
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).
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."
Lua is a GREAT scripting language. >_< And a LOT of people talk about lua. Like this million dollar company. http://www.roblox.com/
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.
I started using Lua as an embedded scripting language to drive a pretty complicated process. After a few weeks, i ended up switching to Python. The Lua libraries were pretty weak, the datastructures and builtin functions were wierd and inconsistent, and swig+python made for much faster scripting then exposing c interfaces to lua.
Oh, and the lack of an integer type seemed to make it really difficult to do proper bit shifting--i'd expect this to be the bread and butter of an embedded scripting language.
We use Lua for embedded scripting in my current project. First I wanted to use Python, but I couldn't figure out how to build our app with MinGW while our Python is Cygwin's.. Lua is very easy to embed, but I think it should be easier to do error handling. We still fail silently on syntax errors in the script..
I am using orbit in various web projects and a lot of lua as an in-game scripting language. I love lua and I am hoping that the community arround lua is going to grow!
The biggest difference between lua4 and lua5 is that lua4 doesn't really have a module system, per se. 5.1 also has a better garbage collector. LuaJIT (which is based on Lua 5.1) is also an option, if you're on 32-bit i386.
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 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.