I’ve spent the last year and a half designing and building a microservices architecture in Go (First rule of Go. Always google “golang”.) After all this experience with Go, it’s finally time to write the obligatory “Here’s why I like Go” blog post. This post, of course, is a required assignment for all real gophers (that’s how golang users are referred to. Cute, ain’t it.) All kidding aside, I’ve really fallen in love with Go. Most of my work is done in Go these days, and it’s a really powerful language, with some good design choices. However, it’s not a panacea. It won’t solve all your problems by itself, and there are some times and places, where it really doesn’t fit.

First of all, for those who have been living under a rock for the past couple of years, and may not have heard of Go, here’s a quick run down. Go, or golang, was invented at Google to solve some problems that they were having with other languages. It’s a systems language (think C) based on C, but with specific design choices intended to make it simpler, and more flexible than C. Wikipedia says that it is “a compiled, statically typed language in the tradition of C and C++, with garbage collection, various safety features and CSP-style concurrent programming features added”. First of all, it’s garbage collected, so no more `malloc` baloney, and shooting yourself in the foot because you forgot to deallocate memory. Second, it’s got a crazy awesome concurrency model built in! This is the thing that gets most people excited about Go. Go makes it dead simple to write highly concurrent software. That’s a post all to itself, so I won’t get into details here, but seriously, it’s damn good. At heart, it’s still just managing threads on the OS, but Go abstracts away the dirty work of creating and managing those threads. Third, it’s a compiled language, which means that deployments become so much simpler, there’s no “dependency hell”, since you can compile a statically linked binary executable. It’s completely self-contained, and you just drop that binary on the machine that you’re deploying to. If you’re my age or older, you might think that’s ironic, since one of the “benefits” of scripting languages (like perl, php, ruby, etc…) was that there’s no need to compile them. It’s funny to me that we seem to have come full-circle there.

With all this Go goodness, are there any downsides? Well, kind of… Go is still a fairly new language, and the ecosystem isn’t as strong as some others. Perl and Python have been around long enough that no matter what problem you’re trying to solve, there’s probably a well vetted library that will help. That’s not necessarily the case with Golang. Of course, that’s changing as we speak. As more and more people start to use Go, more and more libraries get created, and the ecosystem just keeps growing. Golang is designed as a systems language, meaning it provides low level hardware access, so you’re not going to want to write a web CMS with it. With that being said, people certainly can and have written web CMS’s with Go. Personally, I don’t think that type of high level application is the sweet spot for Go. However, I do think that, for example, building a REST API for that web CMS, is a perfect application for Go. And as a matter of fact, that’s exactly what I’ve been doing lately, building REST API’s in Go that provide access to other services and systems.

In any case, Go just works for me. I’m planning a series of posts, where I’m going to go into more depth regarding some of Go’s features that I’ve either very fond of, or that I find myself using all the time. But for now, I just wanted to get back into the swing of writing. I just realized that I haven’t posted anything at all in 2015.