smss79
Rails in particular is very wasteful in terms of connection management, typically checking out the database connection for the duration of the whole request. If you have a machine with 4 cores, one of Rails deployments would start 4 processes each with 10 database connections. So everything you can cache at the connection level (like prepared statements) is now spread through 40 connections across 4 different processes. I believe servers that rely on copy-on-write wouldn't reuse the cache at all.
Using Erlang/Elixir/Scala, you will start a single instance that will multiplex requests across all cores and sharing the same pool. This typically means you have smaller pools, specially if you are not checking out connections for the duration of the whole request, and you can leverage database caches more efficiently, effectively putting less pressure in the database.
Not only that, proper connection pools can actually foresee when requests are not going to be served on time because the database is under high load and avoid sending the load to the database in the first place. We are using such implementation in our ad-serving Erlang system (https://github.com/fishcakez/sbroker) although there is a lot of interesting queue theory regarding sojourn times. Those requests would timeout anyway but the pool can foresee that with high precision and avoid making the database even slower.
In other words, when you say "half of the time is spent in database", it is always worth asking how much of that time is a consequence of how you are interacting with the database in the first place.
Another aspect to consider is if the language (or framework) you are using allow you to depend less on the database. For example, by processing jobs concurrently instead of storing them on Redis/DB, by building distributed clusters instead of pushing broadcasts to third party systems, etc.
> Like any well-designed system that separates concerns. Again, this isn't language or framwork-specific.
While it is true you can implement those systems in pretty much any turing complete language, we expect some languages and frameworks to make it simpler to write certain kinds of systems. For example, doing scientific calculations in Python or Julia is much easier than in Ruby. It it not impossible to do in Ruby but that's just how things are today. Since Erlang was designed for handling millions of connections in a fault-tolerant and scalable fashion, we expect it to shine in the areas previous listed.
> citing resilience, efficiency, scalability, and handling traffic spikes seems thin -- these are all things that can easily be attained with just about any well-factored system on any number of languages/frameworks.
Easily attainable? Err... no? Depending on which system you want to build, it is hard on all languages and Erlang (or Akka or whatever) is going to make it quantitatively less harder.
If your reference point is classical web applications that depend on the database, you still have a single point of failure (even when using primary and replicas). You could use primary-primary replication but that is still a world of pain and definitely not easy. Maybe that's fine for the applications you are building but that does not even scratch the requirements of building distributed systems at scale (and your app server talking to the database is a distributed system).
But we don't even need to go that far to see the benefits of Erlang, Elixir, Clojure, Go, etc. The fact those languages enable developers to use all of their machine resources efficiently should be enough reason for moving on. Rails developers complain about slow boot times, slow test suites, while using only 25% percent of their machine resources (1 of 4 cores, for example). The languages mentioned above have abstractions that make developers more productive and yet they refuse to adapt. We saw this happening with the adoption of garbage collectors and it is only a matter of time for us to take concurrency for granted as we do with memory management.