Some of my thoughts and this is not exhaustive..

In some respects Erlang/Elixir is kind of object oriented when we consider processes. Processes as objects hide their state and respond to messages, they also run in a isolated execution context from other “objects as processes”.

The value proposition for me in Elixir/Erlang was scalability and fault tolerance using a concurrency model that didn’t expose threads, mutuxes, critical sections, semaphores or condition variables. It provided a paradigm that was free of race conditions with a sane approach to serialisable state management through process isolation and inter process messaging built into the core of the language.

Those things and supervision trees/process monitors with guaranteed notification all work together to provide distributed fault tolerance, scalability and mostly lock free execution within a single process/object context.

How many other languages were designed with these realisations?

When I consider OO systems you basically have a complex global mesh of object references and multiple threads of execution crawling all over it and mutating it in parallel. It is no wonder the number of possible edge cases is so much higher and the determinism and reliability of the resulting systems are so much lower.

Object state management in OO was never fully thought through from a concurrency perspective IMO.

Erlang did approach things differently with cheap isolated processes managing state, userland scheduling and process monitors which is why latency is very predictable and we get scalability and resilience with very little effort.

It is also not enough to bolt on immutability on a language where it is not enshrined from inception. The ecosystem is not able to support the developer being immutable everywhere because the standard libraries and community packages don’t fully adopt the paradigm.

When Jose came along and gave Erlang a modern fresh face he dramatically improved the usability and approachbility of the language IMO.

Elixir code can also be a thing of beauty with the functional Create |> Reduce |> Convert (CRC) pipeline paradigm which many other languages would have you writing the steps inside out.

In my view Elixir provides the sweet spot of what I care about from a expressibility, testability, scalability and reliability perspective. I can build solid systems without requiring lots of other tools and supporting components that I would need using other languages.

When I consider the full end to end costs of developing, maintaining and operating a robust service over time, Elixir is the most cost effective technology I have used.

The kind of developers I want on my team can pick it up quickly and appreciate the features that make it a killer solution once you’re live. Even if Elixir is not the most popular language, that is fine by me, the competitive advantage it offers is what actually matters.