In my view and experience, the actor model and the CSP model of Go and others (which is also very similar to Flow-Based Programming (FBP) if using buffered channels), can actually fit together very nicely, with each of them sitting at different abstraction levels:

- The actor model for high-level coordination and communication

- CSP and/or FBP at the low-level, for high performance processing.

The reason for this is mainly that CSP/FBP inherently supports blocking channels between processes when processes are busy (or channels are full for FBP), thus providing implicit backpressure. This can simplify low-level programming a lot, since you don't need to worry about over-filled mailboxes or overbooked CPUs. OTOH, for communication e.g. across a cluster, this becomes problematic since you can't rely on the same level of integrity of the network connections ... meaning that the very communication-intensive nature of CSP/FBP might be less of a good fit.

Thus in my view, the actor model would fit better for communicating between services which are internally implemented e.g. with CSP/FBP.

I wrote a post about this, some time ago:

http://bionics.it/posts/flowbased-vs-erlang-message-passing

It will be interesting to see whether Pony manages to fill more than just the coordination role. Given its much higher raw-crunching performance, perhaps that is the case. I'm a little worried about the lack of implicit back-pressure (due to the actor model), but let's see.

Perhaps because of its high-performance, back-pressure won't be too costly to implement anyway? One can hope. Would be nice with a language that can encompass both programming paradigms, and be suited for the full spectrum between low-level crunching and high-level coordination and communication.