If you dig into the history of Erlang, a primary requirement was fault tolerance. Those phone network devices had to keep running even if one call has an error. Processes and their memory isolation (and supervisors (and hardware redundancy)) were used toward that goal. Concurrency was kind of a happy side effect (especially given CPUs of the 80’s and 90’s).

In my opinion processes should be thought of primarily as a way of controlling the “blast radius” of an unexpected error, and secondarily as a wonderful concurrency primitive that is easy to reason about.

My personal Nr#1 strength of Elixir is that you will be able to write production grade software in less lines of code than any other language. This means you will spend less time to create and maintain it, spend less money as a company to push a feature out and create less bugs for your customers.

The functional nature and process isolation do help here a ton and protect your from a whole class of bugs, while at the same time enabling the “let it crash” way of error handling which again saves you code as it let’s you focus on implementing the “happy path” and deliver value to your customers first.

Compare this with other scalable options, such as Java, Golang, Rust – These are amazing languages but you will spend significant time digging through technicalities to make the borrow checker happy in Rust, or have the correct error handling in Golang or write class boilerplate in Java.

Just my 2 cents.

@ferd wrote a wonderful take on it a few years back, it talks mostly about Erlang, but all of it is applicable to Elixir.