Even outside of web, I find modeling problems the Erlang (and Elixir) way is oftentimes worth thinking about, even if you end up not using it. Concurrency is n

Even outside of web, I find modeling problems the Erlang (and Elixir) way is oftentimes worth thinking about, even if you end up not using it. Concurrency is notoriously difficult, and so a lot of people 'solve' it by avoiding it. That in turn causes you to think about problems in certain ways. Just being free to treat concurrency as essentially free, and in fact, encouraged, starts a real paradigm shift. For instance, from something I had to work on, assume you want to write a cron-like. An 'obvious' way of doing it is to create a priority queue or similar, and keep repeating pop -> execute -> pop -> execute. Then requirements change, suddenly each task you fire has multiple steps to it. So you pop -> execute -> push -> pop -> execute -> push. Then you realize these things take -time- to execute, and that is causing some times to be missed, so you pop -> grab thread from pool -> execute in thread (thread pushes) -> pop. Crap, there's a race condition; is the thread going to push the next thing this item needs in time for the pop? Well, maybe change it, the thread handles all the remaining action items for that job? But what if it's long lived, how does my thread pool look, will we exhaust the pool? Suddenly you have complexity. In Erlang, you just start by defining each scheduled job as a process whose job is to figure out when next to execute the next step for -that job-. You don't need to know about the others. Done.