Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

Which puts it roughly up against the plateau I observe for dynamically-typed languages across the board, except LuaJIT (which AIUI compromises the dynamicness a bit to get there). Ruby is a great deal more than 10x slower than optimal (which is still roughly C, though keep an eye out on that as languages continue to challenge it).

Based on the way Erlang works, I wouldn't expect it to get much past two times faster than it already is no matter how much money is poured into it.

I remember hearing the line about how there are no slow languages, only slow implementations, back in the early 2000s, when we didn't have any implementations of dynamic scripting languages that had really had a lot of effort poured into them, by modern standards. In 2018, we have numerous such implementations with vast, vast amounts of work poured into them. They are faster than they used to be... and they are still meaningfully slower than optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't do all the bad things that Python or Ruby do to make them slow, but it does add a lot of memory copying that Python and Ruby don't do, and which is probably not as reducible as you'd like no matter how you optimized it (the low-hanging fruit, after all, is already in current Erlang).

To be honest, if you like Erlang but you need the next step up in performance and are willing to lose a few guarantees to get there (a very common tradeoff in optimization, after all), the answer is Go, not waiting for a much faster Erlang. Go is significantly faster than Erlang, Go does not have Erlang's memory isolation, and these statements are deeply connected together, not just coincidence.

"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."