Should you go with Google's Go? 7 pros and cons

The once cutting-edge language is taking off -- and may be a prime candidate for your next project

Comments

2016 was full of surprises, but in the world of programming, among the biggest was the breakthrough of Go. Once a tiny niche tool, Go has officially joined the ranks of real programming languages, evidenced by its meteoric rise up the Tiobe index, a complex amalgam of search rankings and programmer preferences. Still a ways behind stalwarts like Java, C, and Python, Go hit 16th in October 2016, up 49 spots from a year prior. That’s a big change that’s caught the eye of programmers and project managers alike.

Go’s jump is likely due in large part to Docker, a package management system for deploying code that is taking over stacks everywhere. The fact that one of the hottest dev technologies in years is written in Go in a positive sign for the language’s viability. A better one may be the fact that Docker is quite solid and very successful. That’s bound to win over converts by showing that the language can support real infrastructure.

Go’s rise coincides with a rapid collapse of interest in C. Yes, C remains second on Tiobe’s list, but it has lost about 40 percent of programmer investment as computed by Tiobe’s complex metric. Built to be a stripped-down, efficient language for writing low-level code, Go shares many features with C, including much of the syntax. It’s hard not to conclude that a good part of Go’s newfound support is likely made up of former C programmers migrating to a new home.

The Tiobe list isn’t about lines of code or job advertisements; instead, it tries to capture the pulse of the programming world by counting web searches and other behavioral metrics. It’s clear from Go’s large leap that people are starting to talk about Go for real-world projects, not merely fringe one-offs from startups. They may not be building them yet, but they’re considering the language. Here we take a look at the pros and cons of Go, a language you can finally mention to your boss and your boss’s boss without worrying about seeming like a nut.

Go pro: Simplicity

The simplest reason to learn Go is that Go is simple, relatively speaking. Its designers deliberately limited the scope of the language and built something that an experienced programmer can learn in an evening. Books for some new languages, like Apple’s Swift, may be several hundreds of pages thick, but Go’s are much, much thinner.

The simplicity has side effects. It’s easier to read code written by other Go programmers because it’s almost impossible for them to use a feature that you’ve forgotten or never learned. Teams can work smoothly together in Go because no one can pull out a weird feature and throw everyone a curve.

Go con: Simplicity

Sure, it’s great to learn a language in an evening. But Go achieved its vaunted simplicity by leaving out dozens of clever, modern abstractions programmers are already using successfully. Most of the ideas that drive the excitement behind languages like Haskell or Swift are missing. While it’s easier to not have to learn all those features, it also means you can’t rely on many of the bug-fighting powers that come with a more complex language. For lovers of complexity and abstraction, Go is a step backward to a time when computer languages were thin veneers on top of assembler, a time when the biggest new idea was adding the else clause to the if-then statement.

Everyone has their favorite feature that didn’t make the Go cut. Some want generics; some want exceptions; some want more extensibility; some want something completely different. For these folks, programming in Go is like coding with one arm tied behind your back.

Go pro: Automation saves time

Go has a number of modern inventions, like the automatic declaration of variables. It seems like a little thing but no one wants to type out letters like int forever. And garbage collection is a big win for everyone who hates keeping track of malloc and free.

Go con: Automation can be dangerous

Everybody who has used automation features in programming languages knows they come with downsides. Garbage collection can be triggered at the wrong time, jeopardizing server code that is supposed to reply immediately. Automatic declaration can get details wrong when the same variable name is used in nested scopes. There’s a reason why people developed belts-and-suspenders approaches to data management and not all new automation features are a step forward.

Go pro: No virtual machine

For the past few decades, languages based on virtual machines were all the rage. The so-called binary code could move easily between different chip architectures, and the virtual machine could enforce some rules on security while doing a bit of runtime optimization. Lots of clever ideas are baked into the best VMs these days.

Alas, starting up a virtual machine takes a bit of time, and Go users don’t need to worry about that. Go binaries are compiled into a nice file that’s ready to (ahem) go. Type the executable’s name into the command line, and it runs when you hit Return.

This doesn’t help the server alone; it also makes it that much faster to test code during development. The debugging cycle in Go is a bit quicker.

Go’s integrated binaries also reduce deployment complexity. Was your Java code compiled for version 1.7? Good luck trying to run it on a machine with a JVM built for Java 1.4. Many servers end up juggling several different JVMs for the various JAR files that supposedly “run anywhere.”

Go con: No virtual machine

Sure, Go has standalone binaries, but they’re huge. If you write a “hello world” example, it will be close to 2MB. The binary is so big in part because it needs to roll in much of the power of the virtual machine. The code for handling garbage collection needs to hang out somewhere. Sure, there’s no VM—because it’s built into the binary.

This past year, Go’s creators implemented a clever feature in version 1.7 to make binaries a bit smaller by stripping out uncalled methods. This is a welcome change, but they still start clogging up the RAM when a server fires up hundreds of versions of your code.

Go pro: Go is like C

Everyone migrating from C sees Go as an upgrade. It has all of the low-level, close-to-the-metal feel of C without any of the gross annoyances that have made C a real headache. Garbage collection is a big step forward that saves plenty of time for programmers and is the simpler file structure. Everything else is pretty much the same. C was a big success. Why break the mold?

Go con: Go is like C

So is everything else. Java, Rust, and Swift are like C, not to mention C#, C++, and Objective-C. They also have more interesting ideas under the hood. There’s more to a programming language than using curly brackets to define the basic blocks of code, but if that’s what you want, plenty of other solutions are more feature-rich.

Go pro: Callback-free syntax

Many programmers who experiment with Go migrate from Node.js, the other speedy server-side stack. When they arrive, they are often overjoyed to escape from the nested confusion of callback routines that call back other routines that call back other routines ad nauseum. (Or really ad buggium.)

The callback structure makes sense for JavaScript on web pages, and it helps offer speed to server-side development with Node. However, it’s hard to keep straight, especially when there are three or four levels of nesting.

Go con: Callback-free syntax

You don’t need to nest the method routines, but you still have to think of coding the interaction in much the same way. Go has channels, but much of the underlying approach is the same. You’re simply changing the way it’s expressed. The nesting of something like Node.js can be a bit annoying, but if you can’t handle that, you probably shouldn’t be trying to get your brain around the architecture in the first place.

Go pro: Libraries

Google has already contributed some of the most important libraries you might ever need for creating server applications. They’re fresh and ready to go. This should make even the most conservative development shops see a little extra promise in Go.

Go con: Libraries are lacking by comparison

Yes, Go has some libraries, but most other programming languages are light-years ahead. Java is the king of installed code, with a bazillion open source JARs looking for love on the internet. This isn’t only Java. Any language that compiles down to run on the JVM can also link to these JARs. Clojure, Scala, JRuby, Kotlin, and dozens of other serious new languages are designed to be compiled to byte code for the JVM, so they can work with all the Java libraries as well.

It’s nice to work with something new, but when something old is so established and powerful, it’s hard not to choose the tried and true.

Go con: False promise beyond its niche

Go’s upswing has been impressive, but it might not rise much further. Many corporate darlings, like Objective-C, never break out of their corporate campus. Other companies don’t want to trust their future projects to a language that is essentially owned by another. Google could easily change its mind or move to another better version, perhaps Go++, that’s not compatible.

While Go made one big jump, it doesn’t mean it will make another one. Java is still the language of AP computer science. C is still the language of Unix. Python is still easier for social scientists to parse. PHP is not only not dying but getting better now that someone figured out how to move Just-In-Time compilers to them. Heck, even Cobol is still rolling along its little niche. None of these is going anywhere, which means that Go probably won’t be able to colonize their domains. Until Go can find new ground, it will likely stay pretty much the same.

Go pro: Its bright future

Features and syntax are fine, but for many organizations, it all comes down to whether the language has legs. There’s no use committing the resources only to find your project is doomed to the dustbin a few years down the road.

While no one can predict the future, Go has plenty of reasons to believe it will be around and thriving, and the biggest of these may be Google’s support. It’s a dominant company with a great future, and as opposed to Google Reader, it seems to be committed to Go. Google is building autonomous cars and other fancy things—the future itself, some might think. Of course Go code will be great and supported, and Go skills will remain in demand.

Is your Go cup half full or half empty? Is its niche comfortable or forgettable? Is the language an irresistible upgrade or a cute hack? Only you can decide.