Maybe you’ve heard of golang (henceforth Go): a Google-born, concurrency-friendly, statically typed language with a growing community of devotees. Although the size of the language’s collection of syntax pales in comparison next to, say, Ruby’s, Go also handles a few key programming concepts in ways that differ from the FP and OOP languages we’re used to so that a seemingly simple question like “Is Go object oriented?” takes 2,505 words to answer.
I began learning Go in preparation for contributing to Diego. One of the first and most comprehensive resources I came across, aside from the Go documentation itself, was a free online manual called An Introduction to Programming in Go by Caleb Doxsey. The book turned out to be an excellent starting point for learning the language. That said, I found myself skimming some chapters, rereading others, and seeking outside resources as I went along. In this post, I’ll use Caleb’s book as the cornerstone of a suggested curriculum for programmers who would like to pick up Go as an additional language.
Before Reading the Book
Pick a project you’d like to make in Go. This is very important.
Ed Weissman says it best: “You don’t need a book. You need a project.”
I did not pay attention to this advice when I started learning. Instead, I worked my way through the book, completing the exercises that the book assigned (so I guess in a way I did make something—an answer key for many of the exercises, which have no answer keys in the book itself. Here it be on Github, if ye should want it. It’s not organized exactly the way the book prescribes, but you can find what you’re looking for my searching the github directory for the name of the method that the exercise tells you to write. Note: in many cases, the solution shown is not the only correct one. Another note: when the book asks you to write a math class is when you’ll no longer find answers in my repo. I decided, instead, to write a physics class in a different repo).
Speaking of which, long after I had finished the book, I decided to put my knowledge and skills into practice on an actual project. Step one: I wanted to import a testing library that’s not part of the core Go, but that Diego uses. This required me to set up a GOPATH. In the process of executing step one, I discovered that I had no clue what I was doing. The book had said nothing about gopaths, and I swear I set that thing up wrong 12 times before I finally got it right. But now, by god, I can set up a gopath. This is why you need a project: you need a thing against which to sharpen your actual skills, not just your perceived (cough, overestimated) skills.
If you have no ideas for a project to build your gobilities, here are some suggestions:
- Implement a math class (relatively easy because the book starts you on this toward the end)
- Implement a library that already exists in your favorite language, but does not yet exist in go.
- Make a Go wrapper for your favorite API.
- “Do something with web sockets.” This was the suggestion of my mentor/supervisor. He was making the point that web socket work makes use of concurrency, a thing at which golang excels. I still intend to do this.
- Got a different idea? Go on with your bad self. It’s your life.
When you start reading the book:
If you already program, you will probably skim the first six and a half chapters of this book. The book is written at an introductory level. So, while the early sections are useful for pointing out how Go differs from your usual language of choice, they won’t contain a whole lot of new information.
Right after Chapter 7, I recommend skipping to Chapter 12.
I’m not telling you to skip chapters 8-11. I’m telling you to skim 1-7, then skip to 12, then go back to 8, 9, 10, and 11, then read 12 again.
Chapter 12 is about testing in Go. If you plan to develop your chosen project in a test-driven fashion, you have to know how to write tests before/as you begin.
After Chapter 7, you will know how to write several flavors of functions in Go, which means you will have the tools to start conceptualizing the innards of your chosen project. If you are like me, you will fail to resist the temptation to write functions for your project. So, if you don’t know how to test, you’re just not going to test them at the start, and then you have to go back and add tests later. Why not test your ingenious functions before you implement them? Testing is not an afterthought: it supports good software design and protects you from a lot of stress.
A word of caution: Go’s native testing library is not the most popular, and you may prefer to try another (ginkgo is decidedly rspec-like in its syntax). If you choose to use one of these, you are adding dependencies to your project, which requires you to set a GOPATH, which is not discussed in Doxsey’s book. Here is the blog post that ended up helping me set a GOPATH correctly after several failed attempts. Keep track of this article. Lots of Go repository READMEs start with “Make sure your GOPATH is properly set” and then just breeze right on to the next step. They’re assuming you know how to set the GOPATH. So know how.
Once you have finished Chapters 1-7 and 12, Chapter 9: Structs, Methods, and Interfaces and Chapter 11: Packages will be the most useful chapters for helping you structure your project. Which files should things go in? How do we do the Go equivalent of class methods and instance methods (hint: the word “method” is used for something more specific in Go than in Java or Ruby)? These chapters are useful for that information. Chapter 9 also provides practical examples of pointers in Go, in contrast to the rather contrived examples in Chapter 8, which is the chapter that actually covers pointers.
Chapter 10: Concurrency covers one of the most exciting things about go: its simple and relatively not-error-prone options for running multiple processes in go. Considering that this rich support for concurrency is the crown jewel of the language, the description in the book is relatively cursory and imprecise. I actually preferred the golang official documentation to learn about these concepts, despite the fact that the golang documentation on the subject, like the golang documentation on all subjects, defaults to jargon at every opportunity. Here’s a more advanced example that nevertheless tries a little harder to break it down.
Chapter 13: The Core Packages discusses Go’s core libraries. Since the book was published in 2009 the Go package stable has become much larger: here is an up-to-date listing.
Chapter 14 discusses how to get better at programming. It’s not germane to the topic of the book, and the views in it are more thoroughly expressed in this talk by Angelina Fabbro and The Hacker School User’s Manual and this trove of writings by Ed Weissman. I highly recommend paying attention to every word of each of those.
After Reading the Book
You’ll hardly need my direction. You have your project, you have the tools you need to turn it into a reality, and you have the internet to help you troubleshoot your way through to your final vision. See? I told you this project thing was a good idea.
However, if you’re looking to cross-train your gobilities, your options include:
- Copying (by hand, not copypasta), modifying, experimenting with, annotating, and committing the example code from the Go By Example library, which conveniently categorizes its samples by concept.
- Subscribing to MetaCasts, in which Mark Bates raves about Go and provides real-time screencasts to illustrate Go’s finer points (Rubyists: think Ruby Tapas for Go).