Orthogonality in Go
I wrote briefly about Orthogonality at the end of my last post but it’s an important topic so I’m giving it its own post.
Also, I seriously can never remember this word so I hope after this post I’ll be cured.
What It Is #
Orthogonality is a fancy word that’s pretty simple for Go. There’s a huge wikipedia definition for it that talks some gibberish, but here’s the gist of it:
Orthogonality means that pieces are independent from each other.
When you change one part of your codebase, you (probably) won’t mess up other parts.
How Go Does It #
Go takes a lot of design cues from the Unix Philosophy.
Again that’s a huge Wikipedia definition, but I trudged through it a few times to boil it down for you, dear reader! Here are the parts that matter for Go.
- do one thing well
- keep things simple
- have a standard way to communicate
Do One Thing Well #
The Go standard library is organized into small(ish) packages that each do one thing well. For example, take a guess what net/http does. Now go into [the package](godoc.org/net/http) and congratulate yourself because you were right.
The package only has an HTTP server and client. Both are very good. And simple, which brings me to my next point…
Keep Things Simple #
The standard library is pretty much a bunch of structs, interfaces, consts, vars and funcs. Just remember is how those 5 things work. If you forgot, use the Go Tour.
Now take those simple things and just start building real stuff.
Simplicity was actually an entire theme of my last post. I talked mostly about the toolchain there but it extends to code too.
Need to build a REST server? We talked about HTTP already, and Go has json support too.
Websockets? yea
Databases? tons
Encryption? take your pick
You get the point. This stuff would take an hour just to find in other languages. In Go, find it on GoDoc and use it.
Have a Standard Way to Communicate #
Unix’s standard communication method is pipes. They let you easily put simple tools together to make a complex program.
Go’s equivalent is interfaces. That doc is not that long but like I said before, I make sacrifices for my readers…
- an interface defines some functions
- if your thing has those functions, it automatically adheres to that interface
- the implementation(s) are completely separate from the interface
- if your thing adheres to an interface, you can pass it anywhere that interface is expected
The standard library defines a few “core” interfaces, and they get used a lot. In the I/O world for example, go learn io.Reader and io.Writer and you’ll go a long way.
Also, if your type adheres to Reader or Writer (or another common interface) your code just fits into the standard library and the community at large. For free.
In case you forgot, it just works.
The Go Way #
The “Go Way” is Go’s culture. And lots of it is about orthogonality.
Orthogonality in Go started with the language design and the standard library. And the pattern grew a community that encourages more orthogonal code.
Today, every new utility, library, code example, etc… makes Go better. Take a shot at writing your own little utility and put it up for some feedback on the mailing list or Reddit.
Or if you’re shy like I was at first, tweet me and I’ll give you some feedback.