I don't think "slow" is the real issue here, but rather concurrency models for IO-bound applications. The way Rails apps often work is that something like unic

I don't think "slow" is the real issue here, but rather concurrency models for IO-bound applications. The way Rails apps often work is that something like unicorn is used to maintain a pool of worker rails processes, which handle requests synchronously. That worker process will block while it waits for IO requests such as DB and HTTP requests. In this model, the worker memory footprint can end up being the problem, rather than speed of execution. Particularly in large Rails with many gems, loading the application can take up to hundreds of MB. This sets a fixed limit for the number of concurrent workers/requests. Rails doesn't _have_ to be used this way, but trying to write a concurrent-safe application in Ruby/Rails can be an uphill battle, because many gems do not work this way. Elixir does not have this constraint, because only a small part of the system (a single actor) is blocked waiting on I/O. This makes it much easier to support many more concurrent requests.