But there's a lot of daylight between what you call "fast" and "pretty fast". For all the effort that has been poured into Javascript, it remains a slow language for general-purpose programming. That's why asm.js could speed up JS as much as it could; if JS was already "C fast" nobody would have needed or used asm.js. And nobody would talk about Web Assembly if JS was already that fast.

It is definitely true that the bytecode interpreters that pretty much all the dynamic languages started with were not the last words in speed, and things like JITs and such have sped them up a lot. When the dynamic interpreted languages were routinely 50x slower than C, there was room for improvement. But there seems to be a wall at around 10x slower than C for general-purpose programming [1] that the languages are having a hard time penetrating from what I can see: http://benchmarksgame.alioth.debian.org/u64q/which-programs-... (Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. It's actually one big graph, I think.)

Having heard people say for many, many years that "languages don't have speeds, only implementations do", I no longer believe that. After vast quantities of time and effort have been poured into the dynamic languages, they're still slow. Just not as slow as they used to be, and often with significantly larger memory footprints to get to "not as slow as they used to be".

NB: Pity LuaJIT is no longer on that site. If you design your "dynamic" language for speed, you can do a lot better. But I've not seen proof you can design a language for convenience and dynamicness and then come along 15+ years later and make it C-fast.

[1]: I have to qualify that, because any JIT worth its salt can optimize certain very advantageous code down to C speed. As the benchmark contains some of these tasks, you can see the dynamic languages with decent JITs reach their tails down to near C-speed in that graph. However, being able to optimize code that loops over integers and adds them up to C speed or even beyond if you automatically use SIMD doesn't mean that you're going to C performance in general.

In Ruby's case, ObjectSpace is worth taking a peek at for an example: http://ruby-doc.org/core-2.3.0/ObjectSpace.html We have here a method that counts all objects, by type, in the entire heap. How, exactly, could one propose to parallelize that? Not Easily. Does that leak synchronization needs -- and thus performance implications -- into every layer of GC, scheduling, class/module definition loading, and so on? Yup.

Doesn't matter how much you approach the pinnacle of excellence in JIT. Some definitions of operational parameters are just going to be expensive. Other languages that simply don't allow such operations are at a permanent advantage. There is no such thing as engineering without tradeoffs.

How wide is your phone? :-)

(It's just to confuse people who insist on saying this language is first, this language is second … as though rank order was useful information.)

http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?

But who is going to finance them rebuilding the whole approach from scratch over several years, in a way that benefits a whole platform rather than just their company, and shelter the team from short-term priorities and reorgs?

That takes a big company that has an enormous economic stake in the entire platform.

And Mike Pall made Lua pretty damn fast.

Arguably one of the most prevalent Java platforms these days, Android, doesn't JIT... it compiles AoT. Java is actually a great example of languages with static type systems being easier to optimize, whereas the JVM is the new hotness for everything dynamic.

Java's main usage (outside of Android) atm is on the server-side, and startup time isn't a huge deal there and you care about cost more than actual perf.