{"id":6001,"date":"2016-07-02T11:52:08","date_gmt":"2016-07-02T18:52:08","guid":{"rendered":"https:\/\/www.ultrasaurus.com\/?p=6001"},"modified":"2016-07-02T12:05:52","modified_gmt":"2016-07-02T19:05:52","slug":"go-language-philosphy-thorugh-proverbs","status":"publish","type":"post","link":"https:\/\/www.ultrasaurus.com\/2016\/07\/go-language-philosphy-thorugh-proverbs\/","title":{"rendered":"go language philosphy thorugh proverbs"},"content":{"rendered":"

Rob Pike’s Go Proverbs<\/a> convey many elements of the Go programming language philosphy in a way that is approachable and fun. He compares with the game of Go, which is “easy to learn, and hard to master.” Inspired by the “Go Proverbs Illustrated” book about patterns in playing the game of Go, he crafted a set of proverbs about the Go programming language. His goal is that proverbs should be \u201cshort, poetic, general, about more than the Go programming language. Contradictory is OK. Life and programming are full of contradictions.\u201d These are ideas to explain to beginners or maybe in a code review. He notes that there are probably many more. These proverbs seek to capture the ideas that make programming in Go different.<\/p>\n

\"\"<\/a>The proverbs with my notes from the talk are listed below. I also found a lovely post with code illustrations<\/a> by Greg Osuri<\/a>, as well as graphically illustrated deck<\/a> with nice icons chosen from the noun project<\/a> and if you have additional proverbs to suggest, there’s now a github repo<\/a>.<\/p>\n

\u201cDon\u2019t communicate by sharing memory, share memory by communicating\u201d<\/strong>
\nPassing on a channel enables safe concurrent, even parallel operations.<\/p>\n

\u201cConcurrency is not parallelism.\u201d<\/strong>
\nThese are often confused by beginners. How these are thought of in the Go community is that they are important to keep separate. Concurrency is a way that you structure your program to make it easier to understand and scalable, and parallelism is simply the execution of multiple Go routines in parallel \u2014 somewhat a less interesting topic than concurrency.<\/p>\n

\u201cChannels orchestrate; mutexes serialize\u201d<\/strong>
\nMutexes are fine-grained and very small, and they tend to serialize execution. If you put a mutex on a variable, then only one thing can ever happen to that variable at any one time (and that is often very important, and sometimes exactly what you want). In the big picture of your program, channels give you a way to structure your program and arrange how the pieces work. As an example, how the \u201cSelect for loop\u201d uses channels to orchestrate your program.<\/p>\n

\u201cThe bigger the interface, the weaker the abstraction\u201d<\/strong>
\nIn Java, you think about interfaces having lots of methods. In Go, we have interfaces which are not declared to be satisfied, they are satisfied implicitly, but even more important is the culture around interfaces that is captured by this proverb. The smaller the interface is the more useful it is. This is a Go-specific idea, we want to make little interfaces, so that we can build components that share them.<\/p>\n

\u201cMake the zero value useful\u201d<\/strong>
\nYou want to make it so that you can use a type without initializing it (if you can).
\nFor example: Bytes buffer or sync mutex — you don\u2019t have to call an init function, you don\u2019t have to call any methods. There is nothing wrong with calling a constructor, sometimes you need that; however, if you can avoid it to make the program nicer, it just means there\u2019s less API there which is always a good thing.<\/p>\n

\u201cinterface{} says nothing.\u201d<\/strong>
\nWhen you are programming and have an empty interface, think very hard about whether that is really what you want…or whether there is just a little something that is really necessary to capture what you need. Sometimes you do need an empty interface, but it is rare. It is overused, especially by beginners. You see this in almost any question on stackoverflow in Go.<\/p>\n

\u201cGofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.\u201d<\/strong>
\nExperienced Go Programmers will say \u201cI don\u2019t like how it formats, but I really like that it formats.\u201d
\n\u201cA little copying is better than a little dependency.\u201d
\nYou can make your programs compile faster and be simpler if you keep the dependency tree really, really small. Sometimes you don\u2019t need that whole library, you just need those three lines of code, that you can just copy and it\u2019s fine.<\/p>\n

\u201cSyscall must always be guarded with build tags.\u201d<\/strong>
\nSyscall isn\u2019t portable — that is the point. If you import it, you must have a build tag for the architecture and operating system that syscall invocation is valid for. If you think you have a portable thing you are using the wrong package. Check out \u2018os\u2019 or something else.<\/p>\n

\u201cCgo must always be guarded with build tags.\u201d<\/strong>
\nSame as above. If you are calling C, god knows what it does! It\u2019s very non-portable. It needs to be built for specific architectures and operating systems.<\/p>\n

\u201cCgo is not Go.\u201d<\/strong>
\nA lot of people in the early days would write about how a favorite feature of Go was how easily it connected to C, but lots of times it shouldn\u2019t be necessary, it takes you out of the Go universe and you lose the benefits of Go if you are coding in C.<\/p>\n

\u201cWith the unsafe package there are no guarantees.\u201d<\/strong>
\nA lot of people use \u201cunsafe\u201d and then complain that things don\u2019t work\u2026 that\u2019s the point, don\u2019t use \u201cunsafe\u201d unless you are prepared to have your program break one day.<\/p>\n

\u201cClear is better than clever.\u201d<\/strong>
\nAmen. There are languages that celebrate cleverness. Go celebrates simple clear code. The Go philosophy values code readability.<\/p>\n

\u201cReflection is never clear.\u201d<\/strong>
\nCommon Stackoverflow question of people wanting to use reflect and complaining that it doesn\u2019t work. It doesn\u2019t work, because it is not for you. Very, very few people should be playing with this. Powerful, yet very difficult to use. We should encourage beginners to step away from using reflection and use the language proper.<\/p>\n

\u201cErrors are values.\u201d<\/strong>
\nBeginners struggle with this. Too often people write \u201cerr != nil\u201d — they think about substituting try\/catch. Errors are just values…<\/p>\n

\u201cDon’t just check errors, handle them gracefully.\u201d<\/strong>
\nThink about whether you should be doing something with errors. People are too quick to just return an error up the tree, instead of designing how it should work. A big part of writing good Go code is getting the error handling right up front. Of any program really, but its easier to program with errors as just values, and easier to do it gracefully.<\/p>\n

\u201cDesign the architecture, name the components, document the details.\u201d<\/strong>
\nThink of really good names for the pieces. If the names are good, the code will be easy to understand and the design will be clear inside your pogram, and programming your system will feel natural. Names should express your design.<\/p>\n

\u201cDocumentation is for users.\u201d<\/strong>
\nThink about what the function is for, not what it does. You want to write something that the programmer using your function will find helpful.<\/p>\n","protected":false},"excerpt":{"rendered":"

Rob Pike’s Go Proverbs convey many elements of the Go programming language philosphy in a way that is approachable and fun. He compares with the game of Go, which is “easy to learn, and hard to master.” Inspired by the “Go Proverbs Illustrated” book about patterns in playing the game of Go, he crafted a… Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":84,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"_links":{"self":[{"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/posts\/6001"}],"collection":[{"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/users\/84"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/comments?post=6001"}],"version-history":[{"count":0,"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/posts\/6001\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/media?parent=6001"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/categories?post=6001"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ultrasaurus.com\/wp-json\/wp\/v2\/tags?post=6001"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}