The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior.

Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"

Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang?

[1] http://www.erlang-factory.com/static/upload/media/1402914329...

[2] http://www.erlang-factory.com/euc2014/frej-drejhammar

Yes. The news is basically "still in the roadmap, we got a bit more of time budget from it" from the OTP team. It is not something you will see tomorrow, but it is a long standing thing in the roadmap for the team.

Of course, if you want to sponsorise the work...

No, same as Go will never be able to match the unique characteristics of Erlang/OTP.

If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here

Anything that's good at handling a lot of I/O or a lot of concurrent processes tends to become CPU bound as more load is given to it.

It's not only about raw computational speed. Being good at concurrency means that you can handle more work, unless you consume too much CPU.

Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely.

A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else.

The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not all roses and butterflies. Also all data is immutable in Erlang/Elixir which makes concurrency a lot easier.

Elixir/Erlang is dynamically typed, but also compiled. At least in Elixir you can use .exs files (usually for tests or config) that are interpreted, but any .ex files are compiled.

probably not. on mostly io bound workloads they should perform similarly but a beam instruction is inherently more costly than a go instruction so on cpu bound workloads go should dominate

however, if you're using elixir/erlang for something cpu bound you're probably doing something very wrong so this isn't a real world concern for most users