As described by Carl Hewitt, the inventor of the Actor model:
- CSP uses named channels (coincidentally called channels in Go) with anonymous processes (goroutines in Go)
- Actors are anonymous channels (mailbox addresses) with named processes (actors).
Carl Hewitt states that CSP was created to create a concurrency model around algebra and having named channels was the only way to accomplish that due to the constraints of algebra.
The Actor model's foundation is in physics. Here's an excellent video of Carl Hewitt giving an off the cuff explanation of the Actor Model[0], and some notes I took while watching it[1] (please add more notes if you can, I get confused about this topic constantly).
Another important note is that there are many different implementations of CSP but only one implementation of the Actor model.
Channels live at a lower level. Usually when you create a channel you share it between multiple goroutines: It acts exactly like a pipe, and are transparent to what's inside. Moreover, goroutines sending to and receiving from a channel don't know (and don't need to know) what's on the other end.
Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
Actors induce a certain paradigm for your application, and I believe Go just wants to give you the tool to build whatever you want. Having channels allows using the Actor paradigm, the other way is not as easy/lightweight.
Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
I don't think this is the case at all. When sending a message to an address you don't know how many actors are behind that address, and even further you don't know how many addresses an actor has. Actors and addresses have a many-to-many relationship.
I think the power of the Actor model is essentially putting your faith in the system and not caring about when messages get handled, or what order they get handled in - it's just knowing that the message will get handled.
The bounded nature of channels tie the communicating processes together more intimately. As a result channels are very good for coordination between processes. Both do a good job of communication between concurrent processes/threads.
Comments
The send/receive paradigm is similar to Actors (Erlang, Akka). What is the main difference between channels and actors?
As described by Carl Hewitt, the inventor of the Actor model:
- CSP uses named channels (coincidentally called channels in Go) with anonymous processes (goroutines in Go)
- Actors are anonymous channels (mailbox addresses) with named processes (actors).
Carl Hewitt states that CSP was created to create a concurrency model around algebra and having named channels was the only way to accomplish that due to the constraints of algebra.
The Actor model's foundation is in physics. Here's an excellent video of Carl Hewitt giving an off the cuff explanation of the Actor Model[0], and some notes I took while watching it[1] (please add more notes if you can, I get confused about this topic constantly).
Another important note is that there are many different implementations of CSP but only one implementation of the Actor model.
0 - http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-...
1 - https://gist.github.com/rbishop/9082539
Channels live at a lower level. Usually when you create a channel you share it between multiple goroutines: It acts exactly like a pipe, and are transparent to what's inside. Moreover, goroutines sending to and receiving from a channel don't know (and don't need to know) what's on the other end.
Actors are more like a combination of a channel and a goroutine: when you send something to the actor, you know what the other end is and you know what it does with messages.
Actors induce a certain paradigm for your application, and I believe Go just wants to give you the tool to build whatever you want. Having channels allows using the Actor paradigm, the other way is not as easy/lightweight.
I don't think this is the case at all. When sending a message to an address you don't know how many actors are behind that address, and even further you don't know how many addresses an actor has. Actors and addresses have a many-to-many relationship.
I think the power of the Actor model is essentially putting your faith in the system and not caring about when messages get handled, or what order they get handled in - it's just knowing that the message will get handled.
The bounded nature of channels tie the communicating processes together more intimately. As a result channels are very good for coordination between processes. Both do a good job of communication between concurrent processes/threads.
This model is called Communicating sequential processes. Comparison between actor model and CSP can be found here http://en.m.wikipedia.org/wiki/Communicating_sequential_proc...