Last year Chima and I were tasked with designing and building CB Insight’s first API. Having no previous API development experience, we were eager to look into which technologies would best meet our needs. We were primarily a PHP shop, but not being very bullish on the language, for reasons I won’t go into here, we were looking at alternative languages to build our API with.
Around this time Go was garnering a lot of attention on Hacker News, and we read as much as we could about the new language. Seeing that Rob Pike and Ken Thompson were two of the three co-creators only peaked our interests further. Among other notable accomplishments, Thompson is the co-creator of Unix and, with Pike, co-created UTF-8 in the early 1990s. Go was their attempt at fixing everything that was wrong with C++, an increasingly bloated language. However just having great co-founders doesn’t make a great language, so we dove in head-first to see what all the fuss was about.
Strongly Typed and Compiled
The first two things we liked about Go was that it’s a strongly typed and compiled language. Compiled code has many advantages when compared to interpreted languages. The checks that a compiler performs can save a programmer time fixing common mistakes and forces the developer to eliminate unused portions of code. Strongly typed languages force the programmer into providing the compiler with useful hints, meaning the compiler can optimize code behind the scenes. All of this helps keep a codebase clean, lean, and efficient.
The two arguments we usually hear against compiled languages are that compilation times can get quite large and that coding takes longer due to the numerous rules the compiler enforces. Fortunately Go’s compilation time is very low when compared to other compiled languages (looking at you JVM languages!). Our compilation time is usually between 15-20 seconds. As for the longer development times, it is true compiled and strongly typed languages take longer to develop with. There are more rules that are forced upon the programmer. However we would argue that these rules help keep our maintenance time to a minimum as we catch more bugs before production.
Go fmt
We love when everyone in an organization naturally codes the exact same way don’t you? When everyone alphabetizes their imports, where brackets are all in the same location, and where indentation is never incorrect? We also love unicorns, but let’s be honest we’ve never seen either. Even if a style guide is developed, enforcing it is another animal. That’s why when we read about Go’s fmt tool we were grinning from ear-to-ear at our desks. Now we have a language standard meaning no matter the developer or organization, Go code will have the same format. Even better if you use Sublime Text you can just use the GoSublime plugin which runs go fmt on your file every time you save. Not only is your code formatted, but it’s one less thing you have to worry about as you code.
Testing
The creators of Go took it upon themselves to improve the experience of unit testing and benchmarking by including a testing package in the language. This package means, that like go fmt, we now have a standard way of testing the language no matter what organization you work for. We also know that because it’s built into the language and used by Google, that it will be highly supported. While we haven’t played around with it yet, we’ve also been eyeing the new test coverage feature in Go 1.2, which automatically generates test coverage statistics.
Notable mention – Go fix
We put this as a notable mention because we haven’t had to use it yet. Go fix is a command line tool that helps update your older Go code to newer versions.
Conclusion
So far we couldn’t be happier with our decision. In the beginning we struggled to find library support for some of the 3rd party services we use at CB Insights, but support has grown large over the last year. Our code base is getting bigger by the day, but it’s still clean, fast, and readable even as we hire more developers. We look forward to seeing with that Go community will accomplish over the next few years and are starting to give back by open sourcing some of our own code. We’ll also be writing more blog posts on our experiences with Go, things we’ve learned, some best practices we’ve implemented at CBI.
PS: We’re hiring
If interested in working with Go and solving hard problems, check out our jobs page.
Written by Robert Mulley and Chima Atufunwa