Thank you for your reply, I myself used channel as a semaphore, i'm not
sure if that is a appropriate use case for channels.
Anyhow your opionion is very welcome
Am Dienstag, 8. August 2017 09:26:35 UTC+2 schrieb Egon:
> 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 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
>> , 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.