19

I was looking into concurrent programming in Erlang and Go programming languages. As per my finding they are used Actor model and CSP respectively.

But still I am confused with what are the objective differences between CSP and Actors? is it just theoretical different only but the same concept?

gnat
  • 21,442
  • 29
  • 112
  • 288
nish1013
  • 291
  • 2
  • 5
  • Well they're not the same since Go provides a different set of primitives than Erlang. Additionally Go is a lot lower level than Erlang and C-like. – daniel gratzer Aug 01 '13 at 10:07
  • Questions about what language, technology, or project one should take up next are off topic on Programmers, as they can only attract subjective opinions for answers. There are too many individual factors behind the question to create answers that will have lasting value. Recommended reading: [Gorilla vs Shark](http://blog.stackoverflow.com/2011/08/gorilla-vs-shark/) – gnat Aug 01 '13 at 10:11
  • 3
    @gnat I disagree, this is asking about the objective differences between CSP and Actors. That's a perfectly reasonable question – daniel gratzer Aug 01 '13 at 10:13
  • 2
    The question is not about good or bad but the different to be determined, thus this question is concrete and not a cause for subjective debate. – nish1013 Aug 01 '13 at 10:13
  • 1
    There's a very nice answer to this question on the CS Theory StackExchange: [What's the difference between the Actor Model of Concurrency and Communicating Sequential Processes](http://cstheory.stackexchange.com/a/188/846) – Jörg W Mittag Aug 01 '13 at 13:35

1 Answers1

21

In practice, there is very little difference: both represent separate units of execution whose primary interface with the outside world is via messages.

The differences are in the implementation details of the languages. Here are a few such details:

  • Channels in Go are typed; if you want to send messages with different data, you need separate channels. With Erlang, one receive gets everything sent to the process and must pattern-match (in Go, you would use a select with multiple cases, so the code would look very similar, just with different channels).
  • Anyone can read or write a Go channel. In Erlang, anyone can send to a process, but only that process will receive. This becomes important if you want to divide a task between multiple workers: in Erlang you need to create a distribution process, while Go can simply share a channel.
  • Erlang provides a (mostly) transparent path to distributing processes on multiple hosts/VMs. Goroutines are confined to a single process (although there are libraries for distribution).
  • Error handling is very different. Erlang treats each process as independent: an error in one process (say divide-by-0) will not affect any other processes unless you explicitly link them (although something waiting for a message from the dead process will hang). Goroutines all run in the same process space; a divide-by-0 will take down the entire program.
  • In Erlang, data is immutable. This means that all communication between a process and the outside world takes place through messages. Go allows you to share state between goroutines (although you shouldn't).

This last point is, I think, the most important. While both use messages as the primary means of communication, Erlang makes much stronger guarantees about how and when state can change.

kdgregory
  • 5,220
  • 23
  • 27