That quote is absurd because the vast majority of applications on the planet are not written in Erlang and work just fine. Working and fault tolerance are in no way related. Being generous the majority of applications with very high uptime are also not written in Erlang.
> If somebody came to me and wanted to pay me a lot of money to build a large scale message handling system that really had to be up all the time, could never afford to go down for years at a time, I would unhesitatingly choose Erlang to build it in
RabbitMQ might be the most famous example of a product written in Erlang. It's great, but I've seen it fall over. In my experience cluster failures typically caused by a handful of root causes like hardware error, resource exhaustion, network partitioning or operator error. Whether a system is built in Erlang or Go, I'd imagine that these same root causes would exist.
I'd love to read in-depth why RabbitMQ's Erlang underpinnings make it better than, say, ActiveMQ or Kafka. Assuming a 3 perfectly built clusters that aren't mishandled, will RabbitMQ somehow "win" over the other two because of some particular greatness in the Erlang?
> the vast majority of applications on the planet are not written in Erlang and work just fine
The vast majority of applications on the planet are bug-ridden, fragile, over-budget, under-thought, mark-missing, user-hostile garbage. They most certainly do not "work just fine."
Ok so we’re adding “developer productivity” on to the list. Aside from moving the goal, one does not have faith a lot faith in the knowledge of people making these claims, like where’s the proof?
