I don't think so. First, just to make sure there aren't any points of confusion... Erlang/Elixir processes are not OS processes (https://elixir-lang.github.io/

I don't think so. First, just to make sure there aren't any points of confusion... Erlang/Elixir processes are not OS processes (https://elixir-lang.github.io/getting-started/processes.html https://elixir-lang.github.io/getting-started/processes.html). As such, we really can't speak of processes in Erlang/Elixir and other kinds of systems on any sort of equal footing. In Erlang, processes are much lighter weight than OS processes. And you do expect them to go wrong... so Erlang has the idea of "Supervision Tree" where there are Supervisor processes whose job it is to monitor other processes and to manage their failure when it occurs. There can be multiple Supervisors which influence one another, or not, as you design them too (thus the "tree" bit). Naturally you plan for these sorts of failures in designing what is/is not a process, what dependencies there may be, what any Supervisor watches and how the Supervisors relate to one another. Erlang/Elixir also seems to have one of the strongest availability and concurrency stories out there on its own. Part of this comes from the aforementioned built in assumptions around isolating and managing failed processes, but the other is in terms of the relative ease of starting processes as needed, and accessing the processes of other Erlang VMs (same server or not). It's clear you have to architect and build things correctly to take full advantage of these capabilities, but I think you can get to the place you describe without necessarily taking on a bundle of different applications for different purposes. For example, for many of the use cases I think of Redis, Erlang offers a number of different ways to deal with such task out of the box: https://blog.codeship.com/elixir-ets-vs-redis/ https://blog.codeship.com/elixir-ets-vs-redis/ Again, you have to think about how you architect things, but you can use the same toolbox for much of the work. I'm still new to Elixir/Erlang, but I've been studying capabilities and architecture for several months now. I think there are sufficient differences in Erlang's approach as compared to other more common stacks that it really does benefit one to come at it fresh and not make very many comparative assumptions. In my own learning I've found that to just get the basic feel for what this Erlang/Elixir animal really is, that the Elixir side is more approachable. The documentation tends to be a little more direct and tends to be more beginner friendly. After I got the very basics down, I was able to look at the Erlang side and understand really what they were trying to say.