Absolutely spot on. And just to pile on a bit more, this part of the blog post gives me the heebie jeebies: There are some actual foot-guns hidden in the ru

Absolutely spot on. And just to pile on a bit more, this part of the blog post gives me the heebie jeebies: There are some actual foot-guns hidden in the runtime: * Reads from a nil map are fine, writes panic * Reads from a closed channel block, sends on a closed channel panic * nil sometimes does not == nil * Any panic in any goroutine kills the entire process * Can't safely store references to loop variables Calling these footguns is an exaggeration. All are natural outcomes of the design of the language. * Zero values are a key concept in Go, and avoid uninitialised memory. Reading from a map returns the zero value of its keys. Writes panic because there is no underlying object. * Channels are another key concept in the synchronisation of goroutines. Block/panic behaves this way because these are programming logic errors. * Equality of interfaces (another key concept) includes the dynamic type. * I'm confused about what the blog author expects from `panic()`? * This is the same behaviour as any language with pointers, such as C. Pretty fundamental stuff. If the author finds this list surprising I wonder about the quality of their software. And this is just cringingly arrogant: > stumped an entire room of seasoned industry veterans for a solid hour