There are trade-offs. Channels are easy to use for simple things, but complicated for complected things.
Locking data-structures can easily introduce data-races (see The Little Book of Semaphores http://greenteapress.com/wp/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 > <http://www.jtolds.com/writing/2016/03/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 to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
