> I think it fits really well in an OO approach, where your messages just become method calls on the actor object -- I believe Swift does that. That’s definite

> I think it fits really well in an OO approach, where your messages just become method calls on the actor object -- I believe Swift does that. That’s definitely true. Here’s what I think of as a motivating example: consider a process that takes input data in an input channel, provides some sort of enrichment, and writes the result to an output channel. Simple, right? Now imagine that enrichment requires some sort of configuration data. And that’s mostly static, but there are regular updates to that configuration that are provided by some sort of side channel. In the CSP model, that’s fine: have the process read from two channels, one with input data and the other with updated configuration data. In the Actor model, you have to read from your mailbox, check if this is an input message or a configuration update, and act accordingly. There’s no sort of OO approach that makes that switch statement feel “natural.” I feel that there’s no point into trying to shoehorn both that input data and configuration updates into the same message queue. Any attempt to do so in a clean way is basically just putting arbitrary functions onto a queue. That said, I recognize that, beyond certain edge cases, the two models are logically equivalent.