There are trade-offs.

Channels are easy to use for simple things, but complicated for complected 

Locking data-structures can easily introduce data-races (see The Little 
Book of Semaphores

The Game/Player example looks weird to me; there's one piece missing -- 
without it, the full complexity is not seen.

With regards to callbacks (context.Done) specifically, in one case you 
control the goroutine it gets executed in, in the other not.

Not closing the waiting channel inside context leaking goroutine is moot... 
when you forget to invoke the callbacks, you will leak as well when you 
have resource releasing in the callback.

Channels are quite good for producer-consumer things, but tend to get very 
complicated for dispatches.

*tl;dr; channels and locking have trade-offs, instead of hopping on the 
bandwagon, understand the trade-offs and pick the one that is most suitable 
in a certain situation.*

+ Egon

On Tuesday, 8 August 2017 09:01:12 UTC+3, snmed wrote:
> Hi Gophers
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> <>"
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
> Cheers snmed

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 
For more options, visit

Reply via email to