Well, by its nature a web request is sequential, so in 95% of the cases it's just: process response -> deserialize -> put/get something from the DB -> send r

Well, by its nature a web request is sequential, so in 95% of the cases it's just: process response -> deserialize -> put/get something from the DB -> send response However, let's say you need to send off many requests to multiple external services in order to respond to a particular request. These would be trivially parallelized in Erlang. Another thing to note is that, let's say Puma is running 8 workers and a bug crashes the app. Every client connected to that worker is going to lose its connection while that worker is restarted. In Erlang, you have one process for each client so only one client notices the crash. And finally, the overhead of starting multiple Ruby processes (in this case OS processes) per Ruby interpreter is way, way larger than a starting multiple Erlang processes. It's a difference of 300MB vs 2KB.