
Comparison of the Go and Erlang concurrency models (2011) - nhjk
http://www.informit.com/articles/printerfriendly/1768317?_ga=1.175054754.1418968640.1417677887
======
javaistheworst
We are using Erlang and trying out Elixir on one of our projects, and so far
it is working out very well - a big chunk of that comes down to the way
concurrency is handled especially in the context of letting things fail,
accepting they will fail, and designing with that in mind. A similar attempt
with Go was perhaps not so successful with the need to bear in mind how Go
models errors and failure within code, which ended up cluttering up the code
quite considerably.

------
4ad
Pretty good article, but a few things stood out to me as questionable:

> In the CSP model, message delivery is instantaneous and synchronous. The Go
> implementation is slightly different: Messages are buffered in channels in
> much the same way that Erlang buffers messages for delivery to processes.
> [...] Go unfortunately misses out on one of the things that makes CSP easy
> to reason about. The synchronous nature of CSP message-passing [...].

Go has both buffered and unbuffered channels; unbuffered channels are the
default. Most code uses unbuffered channels, because, as the author correctly
points out, unbuffered channels are much easier to reason about.

Sometimes you do want buffered channels though, although you quite often want
a buffer size of only one or two.

Buffered channels are the reason why goroutines are not coroutines in the
traditional sense (there was a sibling question asking about that). Unbuffered
channels and GOMAXPROCS=1 (the default) give you coroutines. Go gives you more
if you need it.

------
slimsag
Very neat!

> Go calls its threads goroutines as a pun on coroutines, to indicate that
> they're lighter than real operating-system threads.

A pun? Maybe. But the point of calling them go-routines instead of co-routines
is that they _are not coroutines_.

There isn't a requirement of cooperation on the programmer's part as there
usually is with coroutines (at least as I experienced them in Python, having
to place Yield() calls to let other coroutines run).

With goroutines the cooperation is handled by the implementation/compiler --
i.e. Yield() calls are automatically inserted by the compiler -- rather than
by the programmer manually by hand.

~~~
ds300
> With goroutines the cooperation is handled by the implementation/compiler --
> i.e. Yield() calls are automatically inserted by the compiler -- rather than
> by the programmer manually by hand.

The compiler only inserts yeilds at some call sites. It's not a total solution
like real preemptive scheduling, so you still need to be careful.

~~~
Rapzid
That's old information; every function call causes the check now.

~~~
gtani
Correct from 1.2, except inlined calls, see here
[http://stackoverflow.com/questions/21102078/golang-
methods-t...](http://stackoverflow.com/questions/21102078/golang-methods-that-
will-yield-goroutines)

and [http://dave.cheney.net/2014/06/07/five-things-that-make-
go-f...](http://dave.cheney.net/2014/06/07/five-things-that-make-go-fast)

------
krat0sprakhar
This is probably the most lucid and approachable discourse I've read on the
topic. Thanks a lot for sharing this!

------
leoc
Here's a Yahoo! Pipe that should pull David Chisnall articles out of the
Informit feed:
[http://pipes.yahoo.com/pipes/pipe.info?_id=0dfcf30249eedd880...](http://pipes.yahoo.com/pipes/pipe.info?_id=0dfcf30249eedd88084891578b43f205)

------
sliken
Would be nice to mention it's from 2011 in the title.

