GopherCon 2014 Inside the Gophers Studio with Blake Mizerany

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's example) then you should just use a mutex -- yes! These are well understood truths. Novices to the language have a tendency to overuse channels. Here is Andrew Gerrand addressing precisely this point two years ago at GopherCon: ▶ this video 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'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. It's unfortunate that articles like this are written and gain traction. The explicit instruction to [new] Go programmers is that they should avoid channels, even that they are badly implemented, and both of those things are false.

Rob Pike mentioned variable declaration when asked at GopherCon what he wished he hadn't done in Go ▶ this video

One of the Go developers did say that Go has a big following in China in GopherCon 2014, thanks to Windows. ▶ this video

I would definitely prefer jmpeax's answer. Although, there was a question/discussion similar to this here: ▶ this video The gist was that, if the interface and the structs that are supposed to satisfy that interface belong to the same package, and then you want to prevent any outsider from implementing that interface, you can actually include an unexported method: type HtmlStringer interface { ToString() string isHtmlStringer() } Since it is unexported, no outsider struct can actually satisfy this interface anymore.