“We hold these truths to be self evident…” are inspiring words. Encoding them into a legal framework has been a process. The Declaration of Independence included values of equality and the unalienable rights of life, liberty, and the pursuit of happiness.

Unalienable, adj. impossible to take away or give up
— Merriam-Webster

The authors of that declaration knew full well the dangers we face of those rights being taken away, and yet the first draft of the Constitution did not protect these rights. The first ten amendments were a good start, becoming known as the Bill of Rights. Over 200 years later, we still need to work to define and protect those rights which we believe should be extended to all people.

First they came for the Socialists, and I did not speak out— Because I was not a Socialist.  Then they came for the Trade Unionists, and I did not speak out— Because I was not a Trade Unionist.  Then they came for the Jews, and I did not speak out— Because I was not a Jew.  Then they came for me—and there was no one left to speak for me.

Many people are saying “it will be okay.” We need to step up and work to make that true. Things were not ok before the election.

It is hard to know what to do, but change is not a result of a single action. We need to think through what we may face, so we are prepared when we witness injustice. And we must put ourselves in situations and in company where we will learn and see and have the opportunity to act.

passiflora-july-2016Digging in the dirt, pulling weeds, planting flowers… these things make me feel at peace. There are some activities in my life that I have discovered are symptoms of happiness. My garden blooms, I write, I do the dishes in the morning, and I take longer walks with my dog.

I don’t know that they actually make me happy. I don’t particularly like to write, it’s a way of thinking through things and connecting with other people in quiet, unexpected ways. Writing makes me just a little uncomfortable, but it helps somehow to send these thoughts outside of my head.

I can’t say I always love gardening. It’s kind of boring, but more interesting than meditation and with some similar positive effects. I like how I feel afterwards, and it makes me happy every time I walk by and see colorful splashes of color and so many shades of green.

These small acts of taking care of myself and being present in my surroundings are indicators. I try to notice when they stop, when the weeds grow wild, when I don’t take time to write and the coffee cups pile up in the sink. Today I noticed that I was gardening and it wasn’t even necessary, and I’ve been taking longer walks in the morning. I still struggle and have doubts and there’s all sorts of awful in the world, but when we go out there to face the world, I think we all need a couple of leading indicators of happiness.

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 set of proverbs about the Go programming language. His goal is that proverbs should be “short, poetic, general, about more than the Go programming language. Contradictory is OK. Life and programming are full of contradictions.” 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.

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

“Don’t communicate by sharing memory, share memory by communicating”
Passing on a channel enables safe concurrent, even parallel operations.

“Concurrency is not parallelism.”
These 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 — somewhat a less interesting topic than concurrency.

“Channels orchestrate; mutexes serialize”
Mutexes 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 “Select for loop” uses channels to orchestrate your program.

“The bigger the interface, the weaker the abstraction”
In 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.

“Make the zero value useful”
You want to make it so that you can use a type without initializing it (if you can).
For example: Bytes buffer or sync mutex — you don’t have to call an init function, you don’t 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’s less API there which is always a good thing.

“interface{} says nothing.”
When 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.

“Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.”
Experienced Go Programmers will say “I don’t like how it formats, but I really like that it formats.”
“A little copying is better than a little dependency.”
You can make your programs compile faster and be simpler if you keep the dependency tree really, really small. Sometimes you don’t need that whole library, you just need those three lines of code, that you can just copy and it’s fine.

“Syscall must always be guarded with build tags.”
Syscall isn’t 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 ‘os’ or something else.

“Cgo must always be guarded with build tags.”
Same as above. If you are calling C, god knows what it does! It’s very non-portable. It needs to be built for specific architectures and operating systems.

“Cgo is not Go.”
A 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’t be necessary, it takes you out of the Go universe and you lose the benefits of Go if you are coding in C.

“With the unsafe package there are no guarantees.”
A lot of people use “unsafe” and then complain that things don’t work… that’s the point, don’t use “unsafe” unless you are prepared to have your program break one day.

“Clear is better than clever.”
Amen. There are languages that celebrate cleverness. Go celebrates simple clear code. The Go philosophy values code readability.

“Reflection is never clear.”
Common Stackoverflow question of people wanting to use reflect and complaining that it doesn’t work. It doesn’t 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.

“Errors are values.”
Beginners struggle with this. Too often people write “err != nil” — they think about substituting try/catch. Errors are just values…

“Don’t just check errors, handle them gracefully.”
Think 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.

“Design the architecture, name the components, document the details.”
Think 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.

“Documentation is for users.”
Think about what the function is for, not what it does. You want to write something that the programmer using your function will find helpful.