GopherCon 2014 Inside the Gophers Studio with Blake Mizerany
ConfreaksCited 4× on HN, 2014–2016
talk · intermediate · 2014–2016 on HN
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.
HN commenters cite it as a source for what Go team members said about language regrets and Go's adoption.
Up next
11 mo on HNCppCon 2015: Andrei Alexandrescu “std::allocator...”
CppCon
7 HN recommender · 2017–2025
12 mo on HNLexical Scanning in Go - Rob Pike
GoogleFOSSSydney
13 HN recommender · 2012–2025
10 mo on HNCppCon 2017: Matt Kulukundis “Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step”
CppCon
9 HN recommender · 2018–2026
9 mo on HNRustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West
Rust Programming Language
9 HN recommender · 2018–2023
10 mo on HNCppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
CppCon
13 HN recommender · 2016–2024
9 mo on HNIdeas about a new programming language for games.
Jonathan Blow
7 HN recommender · 2014–2025
9 mo on HNCppCon 2014: Mike Acton "Data-Oriented Design and C++"
CppCon
9 HN recommender · 2015–2026
9 mo on HNHow I program C
Eskil Steenberg
8 HN recommender · 2017–2025
9 mo on HNGoogle I/O 2012 - Go Concurrency Patterns
Google for Developers
9 HN recommender · 2012–2025
7 mo on HNCppCon 2015: Kate Gregory “Stop Teaching C"
CppCon
7 HN recommender · 2016–2025
7 mo on HNZig: A programming language designed for robustness, optimality, and clarity – Andrew Kelley
Recurse Center
6 HN recommender · 2018–2024
7 mo on HNCppCon 2014: Chandler Carruth "Efficiency with Algorithms, Performance with Data Structures"
CppCon
7 HN recommender · 2014–2024
4 comments from Hacker News
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
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.
One of the Go developers did say that Go has a big following in China in GopherCon 2014, thanks to Windows. ▶ this video