←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.412s | source
Show context
__MatrixMan__ ◴[12 Sep 24 16:00 UTC] No.41522335[source]▶
I like that this is a thing, I'm trying to decide how excited I should be about it...

How equivalent are BEAM processes and goroutines?

replies(2): >>41522815 #>>41523150 #
kbolino ◴[12 Sep 24 16:45 UTC] No.41522815[source]▶
Most significantly: goroutines are not addressable. This means that, from application code, you cannot send messages directly to a goroutine [1], you cannot link two goroutines, you cannot terminate a goroutine from another goroutine, you cannot directly watch a goroutine's exit [2], and there's nothing akin to the process dictionary (there are no "goroutine-local variables").

[1]: you usually use channels instead

[2]: you usually use sync.WaitGroup (or similar, e.g. errgroup.Group) instead

replies(2): >>41522875 #>>41540231 #
1. Zambyte ◴[12 Sep 24 16:51 UTC] No.41522875[source]▶
Notably channels differ from actor mailboxes in that they have a capacity, and can block the sender. Mailboxes cannot block the sender, and they do not have a capacity in theory.
replies(2): >>41523022 #>>41523379 #
2. kbolino ◴[12 Sep 24 17:04 UTC] No.41523022[source]▶
The ordinary send operation blocks if the channel is full (or has no buffer), but you can send (or receive) without ever blocking, if you can accept that the message is dropped instead. It's not the most ergonomic operation, though:

    var sent bool
    select {
        case channel<-message:
            sent = true
        default:
            sent = false
    }
3. brynb ◴[12 Sep 24 17:38 UTC] No.41523379[source]▶
with that said it’s quite easy to write an equivalent- https://github.com/redwood/redwood/blob/develop/utils/mailbo...