This has been addressed in more detail in other threads, but I think a fair TL;DR is:
The BEAM (and by extension, Elixir which runs on the BEAM) values the progress of the whole system over the optimal progress of some tiny part of that system.
This philosophy is at the core of all of the major Elixir trade offs I think. The things that make a single process slower when processing CPU bound tasks are exactly the same things that ensure that a CPU bound task can’t lock up the whole system. It’s the things that allow you to introspect and trace in realtime the execution of the system to figure out where the slow parts are on your running production server. Its the things that ensure that if part of the system fails, it won’t leave other parts with invalid memory states. These trade offs are great if you’re running an IO oriented server that coordinates many things or manages many data streams. These trade offs are bad if you want to write say a video codec or a 3d renderer. That’s OK, it’s one of the things I like about Elixir: It is up front and honest about what it’s good at and what it isn’t. It makes clear trade offs.
Addendum: A slightly more realistic CPU bound performance comparison might be JSON parsing, you can find an example here: Crude JSON parsing benchmarks for Elixir, Ruby, Golang. In this case at least, Elixir actually out performs Go.
