I work for a smallish supermarket chain (I assume, by the US standards) - we have about a 1000 stores in 5 countries, about 40-45K tills. At peak trading my teams' services handle a combined 250K tps. We run a bunch of distributed systems in the cloud, across two DCs and some other weird legacy locations (there are even a few mainframes) - the business is really old and went digital before some of my colleagues were born :) (Anyone remember teletext? Yep, we were on that too).

So, Elixir/Erlang combo seems like a perfect fit. Instead, we are having all remaining Elixir and Erlang systems ripped out and re-written in Java.

The reason is simple - readability and hire-ability. The cherries on the cake - Java's "good enough" for what we do, the tooling, the quality and availability of reference resources and subject matter experts - are just that, cherries. But the ability to hire and onboard new engineers is THE thing - it took us 3 years to fully hire out the headcount we were allocated for just our little team and that is in Java. Hiring for Elixir and Erlang has been such a pain that we are having to pay contractors while we re-write the current Elixir and Erlang systems into Java. Our domain is somewhat complicated - most people who have not worked in food retail generally would not imagine it to be so - so onboarding people to the domain knowledge takes 3-6 months and that is without "This is what? Erlang?" barrier. That is where readability of Java and non-FP vs Elixir/Erlang and FP comes in as well.

I guess what I am trying to say is that, yes, the right tool for the job and all that but good enough tool with a significantly higher hiring pool is proving so much better.