Good videos, with context.
GopherCon 2014 Inside the Gophers Studio with Blake Mizerany

GopherCon 2014 Inside the Gophers Studio with Blake Mizerany

Confreaks
0 HN recommenders · discussed 2014–2016
Open YouTube ↗

About this video

A GopherCon 2014 session where Blake Mizerany replaced his planned talk with a panel discussion with members of the Go team. It covers Go's design choices and community questions.

Why it appears in the archive

HN commenters cite it as a source for what Go team members said about language regrets and Go's adoption.

AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.

From the Hacker News discussion

hjr265 · 2014-06 · reference

I would definitely prefer jmpeax's answer. Although, there was a question/discussion similar to this here: [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.

Read original comment ↗
jackyb · 2014-06 · reference

One of the Go developers did say that Go has a big following in China in GopherCon 2014, thanks to Windows. [VIDEO]

Read original comment ↗
xkarga00 · 2014-10 · reference

Rob Pike mentioned variable declaration when asked at GopherCon what he wished he hadn't done in Go [VIDEO]

Read original comment ↗
sagichmal · 2016-03 · reference

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: [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.

Read original comment ↗