Such has been my experience with Ruby for example. The goto solutions for running something in background or periodically (and most of the systems I’ve worked on needed this), such as sidekiq or resque, required running another OS process (job scheduler) and Redis. The equivalent in BEAM can be done with e.g. Task (or e.g. proc_lib in Erlang) for background jobs, and :timer.apply_interval for periodic ones. In a simplest form you don’t even need to add a library dependency, let alone start the scheduler in a separate OS process and manage an external product such as Redis. Will this suit all scenarios? Of course not, but there will be many situations where these lightweight options will work just fine, and allow me to reduce the number of moving parts.
Same thing holds for reverse proxy. Back when I was working with Rails this was basically mandatory, while on BEAM we can get by with cowboy or Phoenix. Back in my days any Rails based production, no matter how simple and small, required nginx, redis, and a separate OS process for the job scheduler. I haven’t been working with Ruby/Rails for some ten years now, so not sure whether things have improved here.
The former sentiment doesn’t negate the latter. A tool can be both useful, but also an overkill in simpler scenarios, as can be seen from the background job & reverse proxy examples. So I prefer to reach for an external tool when built-in option don’t suit my needs. But in general I strive to get by with built-in options, b/c this reduces the amount of moving parts and the number of different technologies used, and I believe we can all agree that, all other things being similar enough, that simplifies things.
I feel that many of the external tools we take for granted are an overkill in many simpler situations (and it’s worth remembering that many of us are not operating at the scale of Facebook, Google, Twitter, Netflix & co), but we still end up using them because there are no simpler alternatives. I feel that BEAM, with its OS-like capabilities, and properties such as separation of failures and latencies through shared nothing lightweight concurrency, has great potential to provide simpler-to-operate alternatives in the form of libraries. A nice example of this is Phoenix, and otherwise we could take some cues from Mnesia or riak_core, which despite all their issues demonstrated that services such as database or distributed system infrastructure can be provided as libraries. I’ve also posted some thoughts on this matter in another thread, here and here.
