Thanks everyone and thanks Haddock for such a detailed response. Few questions:
On Thu, Mar 8, 2018 at 2:32 PM, Haddock <ffm2...@web.de> wrote: > 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). > Why we are calling out its difficult to handle asynchronous programming? I have done many node js project in real world, and for me if once you understand how asynchronous programming works, its simple mental model. I just feel interested, as you have said it would be difficult to handle them. > > 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. > I guess, its 80,000. Should be a typo. Also all goroutines are called as green threads? I read somewhere they start with stack size of 4k, and expand when needed. Correct me if I'm wrong here. > > 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 ... ;-) > > Nice, not sure if coroutines in kotlin are same as Goroutine -- mainly they also work as "green threads"? > > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/uJxcfNsxh-0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
