Why One Developer Chose Go
In the last several years, there has been an explosion of new programming languages. As a developer, you want to evaluate these languages, and determine if you should be investing your time in any of these new languages. So when a language called Go emerged, I asked myself, is it worth looking at?
The decision to even take a cursory glance at it was answered quickly for me. Google was behind this. They know something about the challenges associated with running large scale software initiatives. They have teams of software engineers and face challenges of modern software design. Of course, that left me with my next question. Is this a language that would only work well for Google, or would it fit my needs as well.
First, let us take a brief look at the history and premise behind why Google needed a new programming language. They were facing several challenges. They had a diverse software base that consisted of numerous programming languages. Moving engineers from one team to another could be difficult depending on their skills. Much of the software they had written was taking too much time to compile or test. This lead to long feedback cycles for developers, and hence slowing down the actual development cycle (some programs could take almost a day to compile). Additionally, current languages still allowed developers to write code that resulted in having a category of common programming bugs, such as memory leaks, null pointer exceptions, etc. For more information and detail, refer to the Go FAQ
The goals of the language were ambitious. Create a programming language that was easy to learn, removed the need to make complex programming decisions, had quick feedback cycles, modern language features (like garbage collection), and removed categories of bugs from being allowed to even exist.
Due to such an ambitious goal, Google put together a rock star team which included Robert Griesemer, Rob Pike, and Ken Thompson. Notable past successes of this team (individually or together) include creating Unix, Plan 9, UTF-8, and more. More information on the team and past accomplishments can be found on the Go Wikipedia article.
Ok, so I made my decision. I was going to write some Go code. I rolled up my sleeves, took a deep breath, and prepared to be frustrated for the coming weeks. From previous language learning experiences, I was fully prepared for the pain that comes with creating a development environment for a new language, reading through new code syntax that would make little to no sense, and having virtually no online resources to consult as it was such a new language.
I quickly realized, this was not the case with Go. Installing Go took less than a minute. Writing my first hello world program, again, less than a minute. More to the point, I understood what I did. I was sure I was missing something. This couldn’t really be this easy could it?
Ok, admittedly the success of installing a new development environment on my computer and getting a hello world program running isn’t the same as writing useful, production ready software. So, yet again, I steeled my nerves, and set out to build my first program.
Since most of my background in software development revolved around web development, my first “real” project was naturally a web project. Coming from .Net and Rails, I was unprepared for how “bare metal” Go was for a project like this. I found myself creating more foundation in Go than in these other languages. Initially, this felt like a waste of my time. Shouldn’t some of this boilerplate code already exist? Where was my framework for web development? I was starting to wonder if this was a good choice for a web project.
But, I persevered. After working with Go on a production web project for over two years, it was the best decision I could’ve made. I learned some key points about web development that previously I had never given much thought to.
First, the “boilerplate” that I had to write was fairly minimal in the scheme of the actual project size. It did have an inadvertent result though. I had a very clear understanding of exactly what my web project was going to do, even at a “bare metal” layer. Also, I had 100% control over every part of my web stack. There was no “magic” that many frameworks supply. This was extremely liberating. I can’t count the number of times a framework in other languages painted me into a corner and I had to “hack” my way around it to make it work in production.
Secondly, when I was reviewing my code, I seldom thought “what is this code doing”. Go is written in a way that readability is a priority, and as such, your code is fairly obvious (even boring). This resulted in far fewer bugs, even before I layered testing into the project.
All that being said, it wasn’t a 100% painless experience. There were a lot of questions around the “idiomatic” way to write Go. I also had a lot of the standard “how do you do this” questions (for which Effective Go proved to be invaluable).
Reflecting on the past two years of using Go for production development, I consider it one of the best choices I’ve ever made. While Go is not necessarily suited for all development tasks, it is the one I now reach first, over all other languages. The reasons are simple.
I write the most readable (translated: understandable) code I’ve ever written in my life in Go.
Go is “fast enough” for anything I do.
Go scales very well.
Go is now my language of choice.
Feature image via Flickr Creative Commons.