I would have thought this was obvious, but orders of magnitude more developers know Javascript than Lua[1], thanks largely to the popularity of browsers as a programming environment.

According to some recent research[2], the three primary factors affecting the adoption of a programming language by developers are, in this order:

1. Libraries available

2. Familiarity

3. Performance

And per the paper, this order of preference is extremely strong. Which means, because of the huge mass of Javascript developers out there, that as soon as a library becomes available to do something in Javascript, Javascript will rapidly become the most popular way to do that thing, regardless of the performance hit.

[1] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12... [2] http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap...

Language popularity is a pretty fickle thing. It was not too long ago that you'd be laughed out of the room if you suggested using Javascript for any kind of serious work. Perl, once the king of scripting languages by orders of magnitude, is now viewed as being something close to COBOL: a few old guys know it, but none of the cool kids will touch it.

JavaScript has a uniquely privileged position, though. It is the only language you can use to script the browser. As long as that is the case (and browsers are a relevant programming environment), you will always have web developers who know it, either as their primary language or as a secondary one.

Imagine if the only way you could script Linux servers was in Perl -- it's hard to imagine it falling off in popularity the way it did in our universe. Other languages supplanted it because other languages could supplant it.

The more things change, the more things change. Javascript isn't Perl and isn't being used like Perl. For example, people aren't turning it into an hardware embedded language.

> the three primary factors affecting the adoption of a programming language by developers are, in this order:

> 1. Libraries available

Not just programming languages. Microcontrollers too. You could get much better performance out of a bare AVR, but where are the libraries and modules? Whereas an Arduino comes with a library for anything that moves - of course most people are going to prefer it.

What makes the Arduino non-"bare"? The Arduino language is just C++, which gets compiled using gcc and uploaded using avrdude. It's not exactly running on a VM or using an interpreted language.

Sure, but with Arduino you're still floating on top of the Wiring libraries for almost anything you do. Coding a bare-metal AVR is a bit different:

http://florin.myip.org/blog/how-make-halloween-creepy-blinki...

There's no significant difference, unless you want fully predictable real-time behavior (of which my piece of code is NOT an example, but that's all I have online).

Most people shouldn't care.

You can start with a straight-up Arduino program and mix in as much bare-metal AVR code as you like. There's nothing in between you and the hardware, and that's important when you discover that time matters.

I've done a fair amount of embedded work, some with AVRs and some with various ARM chips, mostly Cortex-M3... I always start with the nice libraries because why waste your time reinventing that stuff if you don't have to? But when you have to reach deeper and gain finer-grained control over your hardware - and almost every project eventually has to do that eventually - it's really, really nice not to have some VM in the way, not to have to start over in a lower-level environment.

Thanks for sharing. I'm working (very slowly at the moment) on an AVR simulator in order to teach myself C. I think this is a great little program to compile and test with.

The Arduino library provides a lot more flexibility compared to the bare AVR + libc, but at the expense of performance. Notably using digitalWrite() can be up to 50x slower than writing to the port registers directly.

Yes, but you can still write to the port registers directly. Using the Arduino libraries doesn't lock you out of anything. There's a smooth, continuous path from high-level C++ abstractions built on the Arduino primitives down to the bit-twiddling low-level C world.

If you're walled off in a Javascript VM, you can never have that kind of transparent access to the hardware - which seems like a big problem when you are building electronics, and controlling the hardware is the entire point of the job.

I think JavaScript might be most successful on Arduino for the same reason - it's a platform with which most tinkerers are familiar.

http://blog.safaribooksonline.com/2013/07/16/javascript-powe...

I suspect Arduino (at least the ones I've used, Uno?) are a bit underpowered for higher level managed languages like JavaScript.

Absolutely. On AVRs, `new` and `malloc` work, but just barely. RAII/stack-only programming is basically a necessity. That is simply not possible with languages like Python or Javascript.

JS doesn't necessarily have to run natively for this kind of programming model to work out. Johnny5, the library discussed in the link I provided, rather provides an interface to the Arduino's StandardFirmata API http://firmata.org/wiki/Main_Pager

To be fair, the Espruino JavaScript interpreter manages this pretty well (in around 8kB of RAM). http://www.espruino.com

Anyone with a tinkerer's mind would not have a moment's trouble picking up Lua particularly if they already knew Javascript (or any other scripting language for that matter).

Also, of dynamic languages, JS is among the most performant, and many times faster than (say) Ruby.

Someone said once "If it CAN be developed in Javascript, eventually it WILL be developed in javascript"

That's "Atwood's Law" The name of it is a hint as to who said it.

Good ol’ Margaret.

Slightly off topic, but is it just me or has Lua gotten a lot of attention on HN in the past weekish? I haven't heard much of Lua before but recently it seems to have come up a lot more.

And even more off topic (sorry), what makes Lua better/different than other scripting languages?

EDIT: On jacobwcarlson suggestion, I Googled Lua vs Python, and found this Wiki, http://lua-users.org/wiki/LuaVersusPython Not a speed comparison, but gives a fair amount of difference in the actual languages. And yes it is on a Lua users site, so may be biased, but on my very light reading didn't seem too bad.

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.

Bare metal Lua: http://www.eluaproject.net/

There was also a project to embed a Lua interpreter in the NetBSD kernel. http://netbsd-soc.sourceforge.net/projects/luakern/

Javascript is becoming(has become?) the lowest common denominator in computing.