# Gopherfest 2015 | Go Proverbs With Rob Pike  ## Metadata - Author: [[The Go Programming Language]] - Full Title: Gopherfest 2015 | Go Proverbs With Rob Pike - Category: #articles - Summary: Rob Pike explains simple design rules and “proverbs” that make Go programs clear and maintainable. Use small interfaces, handle errors as values, and prefer clarity over cleverness. Good docs and simple architecture help teams read and extend code. - URL: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=168s ## Highlights - The name for the language is obviously the same as the game, and that's not entirely coincidence, although it's more of a story. The thing about learning the game of Go is that it's very easy to learn and really hard to master, because it's not like most western games like chess. ([View Highlight](https://read.readwise.io/read/01kedw12x67t2vdnsw9ve129fg)) - there is already one proverb you all know: "Don't communicate by sharing memory; share memory by communicating." I hope I got that the right way around; I usually do. ([View Highlight](https://read.readwise.io/read/01kedw5d7w4rm4mypqghqampt7)) - By communicating, you mean passing on a channel the address of a data structure or an object. Also, the idea is that when you send that object over a channel, if you don't keep the pointer, then you don't have access to it anymore. Safe concurrent or even parallel calculations are inherent in this very model. There's actually a lot behind there; it's a nice rich little thing. ([View Highlight](https://read.readwise.io/read/01kedw5s5ag67nt9t3nrgzt9tf)) - concurrency is not parallelism ([View Highlight](https://read.readwise.io/read/01kedw9aank4x0gw270csxgb2n)) - The bigger the interface, the weaker the abstraction ([View Highlight](https://read.readwise.io/read/01kedw9jbf8athykkd48v9d26k)) - people talk about how unusual it is in Go to have interfaces that are not declared to be satisfied. They’re satisfied implicitly ([View Highlight](https://read.readwise.io/read/01kedwf26bwk1ws87ern01mf8p)) - Note: In Go there's no statement specifying/declaring that a class implements inteface X - rather it implicitly does or does not - the io.Reader, io.Writer, and the empty interface are the three most important interfaces in the entire ecosystem ([View Highlight](https://read.readwise.io/read/01kedwjccfqynxc464g5z438nd)) - if you think about the way that a Java guy would build it, he’d have the interface like this, and you know it would only generalize a little bit because there might be two implementations of it ([View Highlight](https://read.readwise.io/read/01kedwmhzpqm4pttc0h3nkts2m)) - How many implementations of io.Reader are there? I've written programs with 20 implementations of io.reader inside and that's a really powerful structuring plan. So, this is really a Go-specific idea here that we want to make little interfaces so that we can build components that share them. ([View Highlight](https://read.readwise.io/read/01kedwm9rkjd97naqf6c38p0jp)) - Make the zero value useful ([View Highlight](https://read.readwise.io/read/01kedwmypb5yqx2tevg8x69g5c)) - a map of string to empty interface, which is the least useful data structure there is because it's a map of names to meaningless objects. Right? ([View Highlight](https://read.readwise.io/read/01kedwqcysgt2wbbhdhw0cxs8w)) - So when you're programming and you have an empty interface, think very hard about whether that's really what you want or whether there isn't just a little something you could put into an interface with an actual method that really is necessary to capture the thing you're really talking about. Sometimes you absolutely need it; there's no question about it, but it's way overused, especially by beginners. ([View Highlight](https://read.readwise.io/read/01kedwrewxr9p3hrheszztg832)) - A little copying is better than a little dependency. ([View Highlight](https://read.readwise.io/read/01kedwtpysavddfkz871dm3yh6)) - So syscall is always regarded with build tags ([View Highlight](https://read.readwise.io/read/01kedx36d23drcsbt0r0bxnva2)) - Note: When you drop down to syscall, you should explicitly mark which OS/architecture that Go should build from This is not portable - Here's another one: seagull must always be guarded with build tags for exactly the same reason. If you're calling C, God knows what it does right under the covers. It's very, very non-portable. I mean, I know we think of C as a portable language in the old world, but it's really not, and the open source community has made sure that it's become less portable over time. ([View Highlight](https://read.readwise.io/read/01kedx6kj72145009fswmwbha4)) - Note: You should treat Cgo like syscall, there is a specific OS/architecture choice here when calling into C via Cgo - this one is actually about programming in general. You should always be clear, not clever. ([View Highlight](https://read.readwise.io/read/01kedxb32pebxcn1jv3qfmddwd)) - you should be thinking about writing simple, clear code rather than trying to make the cleverest densest stuff you can. That has a lot to do with maintainability, stability, and the ability for other people to read your code, things like that. So it's a philosophical point, but it really is part of the Go philosophy. ([View Highlight](https://read.readwise.io/read/01kedxbv6wp2nwtqdnr7053b6s)) - Reflection is never clear. Another thing you see on Stack Overflow a lot is people trying to use reflection and wondering why it doesn't work. It doesn't work because it's not meant for you. Right? Very, very few people Should be playing with reflection; it's a very powerful but very difficult feature to use. ([View Highlight](https://read.readwise.io/read/01kedxeqe87y754kf43ck6y0ss)) - I think we should encourage beginners to step away from using the empty interface and step away from using reflection to use the language properly. They don't need to use these things nearly as much as they think they do. ([View Highlight](https://read.readwise.io/read/01kedxehmgjvvjcdpp11thrzck)) - Errors are values. This is another one beginners struggle with ([View Highlight](https://read.readwise.io/read/01kedxhyj5dfb63cyng00xqe1k)) - beginners to Go who maybe have been influenced by thinking of errors as an exception or some other control structure, like try-catch, they think of that as substituting try-catch for "if err == nil," but you can't really program a try-catch because it's a control structure; it doesn't work. But errors are just values. You can write code, you can put in for loops, you can store them in variables, you can cache them, you can put them in a map, you can send one to your mother, whatever you want. They're just values, right? ([View Highlight](https://read.readwise.io/read/01kedxkvfsh0f4hzpys63c471w)) - And then, if unrelated to that but just as important, don't check errors; handle them gracefully. You know, don't just write "err = nil," return thing. Think about whether you should be doing something with that error, decorating it with more information. ([View Highlight](https://read.readwise.io/read/01kedxm9m2h4vhqpfma90t0t51)) - errors are just values in Go, it’s easier to program, and therefore easier to do it gracefully. ([View Highlight](https://read.readwise.io/read/01kedxn0tmr1wshdb70ew63553)) - Documentation is for users ([View Highlight](https://read.readwise.io/read/01kedxqc1n3zy4fzpaqgbnmap2)) - think about the documentation you write for your Godoc presentation. Think of yourself as the user of that package rather than the writer of it. ([View Highlight](https://read.readwise.io/read/01kedxq2st10hwq8q6z5mn246t))