[evanmoran]

Let me second this. For example in Go, the simplest way to use a channel is to queue work to it from several endpoints. Then another Go routine can pull it off, usually becoming the exclusive writer of whatever the next step the computation is.

So even though Go has this green/micro thread behavior behind the scenes (go routines), it’s main innovation is around the concurrency safe queue (the channel) so those threads can communicate.

Now with actors you can imagine more of a pattern where each holds its own state and messages cause them to modify themselves or send messages to other actors. This behaves more like AI in a game simulation and is useful if independence rather than coordination is a good solution to the problem.

For lots of services this is not the case as the fastest path through all the queues is the best path and the problem isn’t about deciding what to do independently or hiding state within the actor but throughput through known paths. So that’s the difference. If you are tagging video with ML you want queues and throughput, if you are reacting to routing networking messages based on simple rules (erlang) you want actors.

[lostintangent]

I _really_ appreciate this reply! Naively speaking, when I look at actors, I just can’t think of why they’d be superior to coordinated queues/channels, except for within an arbitrarily configurable, rules-based system (e.g. game NPC behavior, network routing). But I couldn’t help but assume this was dramatically oversimplifying the problem/missing the point.

If someone were using Go routines and channels, what do you think is the “clear” moment that they would benefit from actors? When the sequence of steps in a workflow are non-deterministic?

[iampims]

Because they scale to more than one node is a very important feature.

[lostintangent]

True! But you don’t need actors to enable horizontal scaling?