but also
Choose the right tool for the job.
Plenty of people build highly tolerant, robust distributed system of top of regular languages when Erlang exists, and no one bats an eye. Erlang is no magic sauce, but for its niche it is unrivalled and yet routinely ignored in favour of subpar platforms because of dubious concerns such as "there are no Erlang/Elixir developers around", which is nonsense.
The true reason is that there are plenty of engineers and architects that have no exposure to the BEAM, so have no idea how productive they could be developing their distributed system on it. They simply do not know what Erlang & co. could do for them.
Certainly, but for each and every small task you do, you don't evaluate a new language for it. If you have a web application that's done in Rails and have a bunch of Ruby programmers, if you need to, say, add a simple web scraping system to it in house, you're likely going to reach for a Ruby tool at first.
On one side, you have shops that are like "we only use Java". They're maybe missing out on some good tools for various tasks. The other extreme would be a big list of languages, and that's difficult to maintain as people come and go.
Are you building a distributed system? Are you building a highly concurrent IO-bound server? Are you building a system that needs to be fault-tolerant? Going for anything other than Erlang/Elixir is a misinformed choice.
The thing is, most people don't start out wanting a distributed system, it's something you get when you've scaled to a certain size.
If you know you need it, and Erlang's version of it is a good fit, yes, it's a good way to start.
I find that is often a lot more relatable to average-joe-tasks than bigger picture distributed ideas, even if they're actually the same thing at their heart.
I just don't want one request to blow out the system, or some sporadically turned remote API to hose everything, Elixir gives me that (with the simplicity other languages often need other stuff stuck onto to handle).
Your options are
* Keep trying to restart it forever if it fails (by setting the timeout so low that it'll keep trying)
* Try a set number of restarts, then pass the failure higher up, potentially taking down the whole system if there are enough failures.
* Just let it fail and walk away.
https://www.erlang.org/doc/design_principles/sup_princ.html#...
If you have something like a web site with a database, where 1) the database is critical to the normal functioning of the system, but 2) you still want the site up to let users know that "it's broken and we're fixing it", and maybe also send some alerts out, you might want something more like an exponential backoff or some other more involved strategy, which isn't shipped with Erlang.
In fact, I am writing this week a dynamic process pool in Elixir which is so peculiar in its requirements I don't think I've ever seen anywhere, and it's in total 500 lines of code spread over 2 GenServers (+ Registry and DynamicSupervisor). I reckon it would easily be 25x as much in C++ or Rust.
If you want exponential backoff, I suppose it should be pretty easy to implement with a custom Supervisor (though the best practice would be to have a sidecar GenServer to deal with the backoff/alerting business rules, and using a regular Supervisor.)
Back in the day, I found this to be a pretty good 'circuit breaker' type of thing: https://github.com/jlouis/fuse
I wrote something similar for the (OTP) application level: https://github.com/davidw/hardcore
If your BEAM app goes down because your GenServer crashes, something is terribly wrong with your code.
We've been able to easily scale with minimal effort and have never had downtime.
I am not at all saying this is you, to be clear, but one problem I have had in the past looking for Erlang jobs is that occasionally you find people who view it as some kind of magic sauce, or "I'm curious to see what it's like".
In the former case, they think just writing their code in Erlang is going to give it magic scaling powers. This is probably less common these days, but I recall a while back when Erlang first got a bit of hype, there were people who weren't thinking very clearly about it.
In the latter case, sometimes it's not the best tool for the job but someone wanted to learn the intriguing new thing.