Lua is a language designed to be embeddable, Javascript is a language that didn't even had the chance to be properly designed.

Although I'm one of those Lua "unadopters", for me it's better to simplify stuff to my audience, and I have considered seriously to use JavaScript for my next project instead of Lua.

Both javascript and lua were designed for very similar goals. It just so happens that the designers of Lua had more time to do it- plus they aren't burdened with the need to always be backwards compatible, so lua (now at version 5) breaks scripts written for older versions.

So they each have their trade offs.

I'm pretty confident that if Lua were as widespread as JavaScript is, a backwards incompatible change would be less likely to happen, although with Corona SDK, I'm also confident that Lua will have an opportunity to shine :).

I"m not sure that "widespread" really would do it. The other difference between Javascript and Lua is that- while Javascript has been embedded in adobe software, modified to become actionscript, and is the scripting language in some games, its primary use has always been the web- with its specific DOM api. The web carries with it the backwards compatibility burden.

Lua doesn't have to be backwards compatible because nobody has to upgrade to the latest version of lua- and there isn't much of a standard library to break anyway- All the things you'd traditionally use a library for are provided by the outer application lua is embedded in- an application likely not written in lua itself- and so if you do decide to upgrade your app/game the only thing you break is individual scripts.

With a widespread adoption more security-related issues and bugs get discovered, with new security-related issues and bugs comes new fixes, and those fixes (especially the security-related ones) IMO are the incentive to update.

Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment.

Your product exist because it solves a problem, and the moment your product gives more problems than the ones it solves, you discourage your users to use your product and they begin to look for options, and if an option that meets their needs doesn't exist they will stall (ex. Windows XP).

This means extra effort, since you have to maintain at least the most used major versions, and at the very least provide security updates to your users. Fragmentation is a <s>headache</s> migraine that you want to avoid whenever it's possible...

With a widespread adoption you have to evaluate deeply whether the fragmentation troubles are worth the value the backwards-incompatible changes will provide. It's not the same trouble having a hundred users, than having a billion users.

You're not wrong, but I think with lua the fragmentation problem is pushed out to the app developers who embed lua in their various games and applications. Do the developers of lua concern themselves much with this? I suppose slightly, but mostly in the form of documenting what's different and how to convert old code to new code. The lua philosophy seems to be that a simpler/smaller implementation trumps backwards compatibility.

You are also right, but when a project has small adoption, usually the users are people that feel identified with and like the project.

But suddenly the project becomes a product, and the product gets adoption (every time more).

The users will use your product because of different reasons (ex. it's what other people use / it's what can solve better X problem / it's what I got recommended / etc.), the users that like and feel identified with the project become a small niche in comparison with the people that need the product.

The users become the ones that shape the product, you have to balance between:

Feature A. Which is what you want to do for the project. Feature B. Which people are telling you they need for the product.

Will you develop exclusively "Feature A"s, because you are following a philosophy?

Think for a moment what would had happened if Microsoft had adopted Lua for IE3 instead of reverse engineering Netscape's JavaScript (assuming that IE would have still won the 90's Browser Wars thanks to Lua). Are there flying cars in that parallel universe? Is Lua uglier than today's JavaScript? Has Douglas Crockford written Lua: The Good Parts yet? :)

I'll leave the pros/cons of the language itself to others, but two of Lua's most attractive aspects are its size and speed. The interpreter is something like 200k and is built to be embedded into anything. For instance, RPM has a Lua interpreter embedded into it and here's Dino's paper about using it in 'sploits: https://www.usenix.org/legacy/event/woot07/tech/full_papers/... Benchmarks are notoriously unreliable but I encourage you to Google around for Lua v X language. It's _very_ peppy.

I don't know where it is coming from as well.

But one area where Lua is gaining traction is because it is the only high level language that is integrated with Nginx.

Bug, not feature.

Running your own code inside your front-facing web host was bad when Apache brought in mod_php and is bad now.

Lua is elegant, small and fast, especially when you're using LuaJIT. It's the language I reach for first when I need to embed a scripting language in a system (perhaps to replace configuration files).

Its only real drawback is a lack of libraries/package manager compared to, say, Python/Ruby (respectively). I guess some people might miss built-in support for classes.

There are package managers for Lua. The main one is called LuaRocks.