←back to thread

Ergo: Erlang-inspired event driven actor framework in Go

(github.com)
175 points nateb2022 | 3 comments | 12 Sep 24 11:06 UTC | HN request time: 0.758s | source
Show context
Xeoncross ◴[12 Sep 24 14:01 UTC] No.41521090[source]▶
Never having worked with Erlang, my mind is telling me this might be an alternative for https://github.com/temporalio (database-backed functions) or AWS Step functions.
replies(1): >>41521544 #
seneca ◴[12 Sep 24 14:41 UTC] No.41521544[source]▶
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.
replies(1): >>41521715 #
brightball ◴[12 Sep 24 14:58 UTC] No.41521715[source]▶
Supervisors give you the durability though.
replies(1): >>41522827 #
jerf ◴[12 Sep 24 16:47 UTC] No.41522827[source]▶
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.)
replies(1): >>41526438 #
1. brightball ◴[12 Sep 24 22:48 UTC] No.41526438[source]▶
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.

replies(1): >>41527506 #
2. jerf ◴[13 Sep 24 02:18 UTC] No.41527506[source]▶
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.)

replies(1): >>41533437 #
3. brightball ◴[13 Sep 24 17:46 UTC] No.41533437[source]▶
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.