When I say crash tolerance, I mean the entire system going down. Given the emphasis on async BEAM processes, which all work in memory, I find it hard to understand why they're more reliable than the "standard" approaches of SQL dbs or crash-tolerant queues like kafka.

Take this example from the article:

  def handle_call({:process, order}, _from, state) do
    customer = Customers.fetch!(order.customer_id)
    charge = PaymentGateway.charge!(customer, order.total)
    Notifications.send_confirmation!(customer, charge)
    {:reply, :ok, state}
  end

I'd assume we want PaymentGateway to commit to a DB. But there's no transactionality with notifications, hence notifications can be lost if the entire runtime goes down. For an article trying to "sell" BEAM to me, I just don't see the value.

I guess maybe the question is why use BEAM if it also doesn't solve the general systems are problem?

I interpreted the tone of the article to mean it does solve all these problems. Resulting in my general confusion as to the actual advantages. I think this whole actor business somewhat reminds me of the Smalltalk people saying it's all about message passing, but I just don't understand what's the difference between passing a message to and object, and doing obj.function(message). At least for BEAM the whole supervisor tree seems neat, but other than that, it sounds like go routines with channels, or just a queue in python.