The recent Erlang release (21) changed a lot of the internal interpreter structure with a nod in Mike Pall's direction. Just by shortening the typical opcode size down, they gained 20% speed boost. And the BEAM is a pretty good interpreter anyway.

JITing the beast has been a want for a while, but there are also other paths taken right now which can provide speed boosts, among other a translation of the compiler to use SSA-representations.

Erlang, I think, is crippled out of the box wrt performance by its emphasis on immutable data, live troubleshooting, small processes with lots of messaging, etc.

These are the things that make it a brilliant language for use cases where it's well-suited. Not every language has to be a kitchen sink language like Java, thankfully. I like opinionated languages with well-defined strengths and weaknesses.

The architecture of the BEAM is quite complex.

I don't believe you could reach the same raw performance that you have with go.

However it is an unfair comparison, BEAM processes do much more than coroutines.

The BEAM is already much more performant than, for example, the Ruby reference implementation. And look at what people have managed to build with Ruby!

Erlang 19 is only 10% faster than CRuby 2.3 on a simple factorial bench. Web throughput is even closer as lots of it is C extensions.

I haven't made the comparison myself for a while but I suspect it's still very close.

I don't think it's going to happen, due to the stack+heap per process and lack of shared memory (ok yea ETS sure) which you need for fault tolerance, necessarily requiring more copying than conventional languages. I think there are different tradeoffs that make good CPU bound performance (like Java or Go) on BEAM pretty much impossible.