The main difference is that goroutines do blocking takes from channels whereas actors receive asynchronous events. This means that actors have to deal with all the situations in asynchronous programming that are inherently difficult to deal with (inherently means there is no general way to solve this and never will be).
The approach with blocking takes as in CSP and in Go runs into a problem when a thread blocked by an empty channel is lost for the application. Somehen then operationg system has no memory left to create new threads. This is being dealt with by having so called green threads (called goroutines in Go). Green threads have a reduced context and therefore consume less memory. On a machine with 4 GB RAM you can create about 2000 OS threads but about 80.000 goroutines (I once tried it out). So in Go you don't run into the problem that many empty channels with threads being blocked by them till they receive input can make the application go out of threads. Actors have an advantage when used for distributed systems. If two actors on different boxes communicate with each other it is not a problem to make communication work without data loss through the principle of supervision. Supervision is the idea Joe Armstrong (the creator of Erlang) described in his PhD thesis. If two actors communicating with each other, realize something in the communication must have gone wrong (timeout waiting for ack, etc.), a third supervisory actor is informed which resets both actors who then restart from some safe point. There are hierarchies of supervisory actors to deal with the problem that also a superviory actor may hang or be subject to data loss. Also, actors are served by normal threads (making use of thread pools to keep the number of memory intensive threads low). These normal threads do not have a reduced context, but a full one. This means that the information is present where some preemption took place where the thread needs to continue when resumed after suspension. Not so for green threads, because of their context being reduced, they are not pre-emptive. The developer in some situations needs to know that the current green thread/goroutine needs to yield for things to continue. Channels in Go or CSP in general, on the contrary, rely on data exchange between channels to be free from any data loss. Otherwise the application may sit forever on some empty channel. This is no problem for channels inside the same instance of some program, but it is a problem in distributed systems that have to deal with communication through networks being unreliable. In general with CSP-style concurrency it is much easier to get process synchronization right. If there is a problem, it is much easier to spot it and also to fix it. If have spent years of reproducing race conditions and deadlocks and fixing them with "traditional" programming languages without CSP. Saying that CSP makes concurrent programming much easier is something I can confirm from real-world experience. But they don't work well in distributed systems and when pre-emption is a necessity (shut down nuclear power plant when temperature threshold is exceeded here and now). There is also CSP in the working for the JVM with Coroutines in Kotlin and project Loom for the JVM. The advantes of CSP for server-side programming and concurrency in general have become apparent also to other people ... ;-) Am Sonntag, 4. März 2018 18:00:54 UTC+1 schrieb Anto Aravinth: > > Hello All, > > I'm new to golang and trying to understand the difference between channels > and actors. From my knowledge: > > 1. Golang support channels, which is concurrently safe > 2. Channels can be shared across goroutines that are running. (very much > similar to messages) > > Actors: > 1. They are based on messages. > 2. Messages are immutable by nature. > 3. Actors work based on messages, concurrently. > > I find actors and channels much similar, may be I'm wrong here. Any help > would be really good. > > Thanks, > Anto; > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
