Ergo: Erlang-inspired event driven actor framework in Go

They're not the same, exactly, but there are similarities. The actor framework isn't inherently durable workflows, for example. It does similarly distribute work though.

Supervisors give you the durability though.

A different kind of durability than what people mean by "durable workflows", though. Durable workflows require durable storage of their current state; supervisors give you durable computation services. Supervisors don't even guarantee "durable computation"; if a process crashes halfway through processing a request, it's not like the request will be automatically retried or something. (That isn't even a good idea, there's a very good chance the reason why that request crashed one process will crash others.)

You can actually set it up that way though. You set a process to keep the state and a process to do the work. If the process doing the work crashes, the state is preserved.

It’s a deliberate decision but very easy with the BEAM.

That's still not durable; you've set up a single point of failure in whatever is hosting the state process. Durable storage is a fundamentally different problem which you can't solve just by waving some Erlang processes at the problem. You could write a durable storage system in Erlang, although there's not a hugely compelling reason to do so when you can also use any existing one, and writing this sort of system is extremely challenging. Heck, just (fully) understanding Raft or Paxos is extremely challenging, let alone implementing it. Some classes of problems are best solved by a limited number of best-of-breed solutions that all of the other language ecosystems just use, like, durable storage and databases in general, or ffmpeg, or browsers.

(I can also tell you from personal experience Mnesia isn't a "durable storage" solution. Rather the opposite, honestly.)

I need to find the link, but I saw an incredible presentation at Gig City Elixir last year where they’d been running a globally distributed, in memory, medical database with no downtime or data loss for upwards of 5 years. One of the coolest projects I ever saw.

But yes, you do have to determine state and recovery patterns. Depends entirely on the situation but things like making sure your data will survive a process crash is straightforward.