That's a pretty good write up.

There's a fine line between making things easier and more readable and having less boilerplate code, and pouring a bit too much magic and macros into things.

I'm always curious to see what people do with Elixir. The BEAM environment offers a lot in terms of a platform, but if you're just using it to serve web dynamic web pages, Rails is going to be a better pick in some circumstances because of the huge number of libraries, people who know it, documentation, hosting and the rest of the ecosystem.

The transparent parallelism makes it an amazing fit for pretty much anything and everything that doesn't require minimum system resources and microsecond-level of response times.

1. Web apps work awesomely because they tolerate sudden bursts of load much, much better than Rails. Rails deployments regularly fall over on bursty workloads unless complex load-balancing setups have been put in front of them.

2. Which brings me to: operations / infra story is much simpler, and it is thus cheaper and easier to maintain Elixir apps, even when they span multiple nodes (because Erlang's builtin mechanism to do mesh networking / distribution works well enough for 99% of the projects out there).

3. Complex service trees f.ex. scrapers that also present their data in a visual CMS backoffice UI and background tasks infrastructure -- all of that can live on literally the same node, share the same code repo and be very easy to manage and maintain as a result.

4. Oh, that also reminds me: almost anything and everything you would need Redis for, you can have it natively with Erlang/Elixir.

5. Corollary to point 3: long-lived daemons that are not even web apps / APIs work really well under Elixir due to the supervision tree guarantees of Erlang's underlying OTP framework. If you configure it well (the defaults are not always optimal) you can have your invisible mesh of services survive extended outages of the 3rd party APIs it depends on.

6. In the last years, LiveView and Livebooks are amazing additions that help severely reduce the need of JS and provide an alternative to Jupyter Notebooks, respectively. Though it has to be said that LiveView works best when the latencies to the backend aren't too big, say, 200ms or less. Beyond one certain human perception threshold it starts to feel sluggish however.

I could go on and on and give plenty of examples from my career. I've replaced a lot of shell scripts and PHP / Python / JS services with Elixir, and each migration was a crushing success in every way. We're talking 15+ such projects. Only 1-2 of them got back to their original language simply because the companies / teams were too risk-averse and didn't want to hire Elixir devs (or train their current people). But the network effects are always a chicken-and-egg problem; if people never want to bet something on the tech then it obviously is never going to be appealing to them.

There are many who made the plunge though and are happy with the results.

> If you configure it well (the defaults are not always optimal) you can have your invisible mesh of services survive extended outages of the 3rd party APIs it depends on.

This is something that annoyed me a bit with OTP. The basic strategies aren't really enough for that, so you need something like https://github.com/jlouis/fuse

I wrote something like that myself, but it hasn't seen a ton of use: https://github.com/davidw/hardcore