Go channels are bad
This is a frustrating and overly-exasperated post which reaches conclusions that have always been part of the Go canon. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose -- yes! Channels are useful in some circumstances, but if you just want to synchronize access to shared memory (like the author&#x27;s example) then you should just use a mutex -- yes! These are well understood truths.<p>Novices to the language have a tendency to overuse channels. Here is Andrew Gerrand addressing precisely this point two years ago at GopherCon: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=u-kkf76TDHE&amp;t=815" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=u-kkf76TDHE&amp;t=815</a><p>Neither the referenced performance characteristics via Tyler Treat, nor the FUD surrounding channel-based program architecture, invalidate channels generally. One does have to think carefully about ownership hierarchies: only one goroutine gets to close the channel. And if it&#x27;s in a hot loop, a channel will always perform worse than a mutex: channels use mutexes internally. But plenty of problems are solved very elegantly with channel-based CSP-style message passing.<p>It&#x27;s unfortunate that articles like this are written and gain traction. The explicit instruction to [new] Go programmers is that they should <i>avoid</i> channels, even that they are badly implemented, and both of those things are false.