I’ve been doing Erlang professionally for the last few months. I have to say, it’s a breath of fresh air after decades of Java/Scala/ /golang/. It’s unfortunate it isn’t more popular.

OTP and Erlang make it so easy to build distributed systems end to end. It makes my past professional efforts look like a shoddy amateurish joke. If you find yourself needing to build a distributed stateful service, Erlang/OTP should be the top choice.

What are you using it for, out of curiosity?

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.

Edit: and of course there are great use cases for it. See my other comment elsewhere on a system where it was a great fit. I'm always curious to see where others are using it successfully.

There is no silver bullet.

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.

> Choose the right tool for the job.

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.

Erlang is not just a language, is a different paradigm, and it is worth evaluating, just like deciding whether you need a native language, or Python's enough.

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.

For me the question often hasn't been "is it distributed" but "how often do you need to spawn some async task (that can be run supervised, or unsupervised, in a fault tolerant manner)".

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).

It's kind of ironic that stock Erlang/OTP has fairly crude tools for "spawn some async task" and deal with it failing.

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.

There are infinite ways of dealing with failure. Erlang gives you the building blocks, if you need something more complex, you're supposed to have to write some code. How is this surprising?

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