8 reasons developers love Go—and 8 reasons they don’t

In 2007, some of the programmers at Google looked at their options for writing software and didn’t like what they saw. They needed to manage millions of lines of code that would be constantly storing and shipping data for the world wide web. The code would juggle thousands or maybe millions of connections on networks throughout the globe. The data paths were full of challenges from race cases and concurrency.

The existing programming languages weren’t much help. They were built for games or managing desktops, or many of the other common tasks from a world before the web browser. Their rough edges and failure modes drove coders at Google crazy enough to start asking if there might be a better way. Was there something that could handle the I/O chores in just a few lines with all of the safety and security that Google needed?

The answer to that question was no. And so they created Golang, a simple language that is superficially similar to C or Java. The public versions started appearing in 2009 and the first 1.0 version shipped in 2012. Today, Google continues to invest in the language, and the latest stable version as of this writing is 1.22.5.

Inside Google, the Go language powers large blocks of the infrastructure, and it’s also been embraced by many programmers outside of Google. The language recently climbed into the top 10 of the Tiobe index. It is sitting in the eighth position as of this writing.

All of that outrageous fortune has delivered plenty of plaudits—but some slings and arrows, too. In many cases, the same features bring both disparagement and praise. What some developers love about Go, others hate just as much. 

8 reasons developers love or hate the Go language

• It’s easy to learn
• It doesn’t play favorites
• The C-based syntax
• (Too) many rules
• Extra error handling
• The standard library
• The executable size
• Big daddy Google

Go is easy to learn

Go’s designers deliberately created a language that would be quick to learn, because it didn’t have too many complex features or idiosyncrasies. Instead of adding bells and whistles to Go, they chose to strip the language down, close to the bare minimum needed to accomplish their work at Google. That meant saying “no” to good ideas and focusing on an idealized vision of what programmers should need.

Why some love it: A simpler language is easier for new programmers and team members to learn. There are fewer features or constructs to master and that means skilled programmers can pick up the language in a day. Staffing projects is easier because old dogs can be taught Go’s new tricks quickly. Not only that, but the code is often easier to read, if only because there are no strange or arcane structures that appear in odd places.

Why some hate it: Simple isn’t necessarily bad, it’s just what was left out. Would a witch choose an abridged spell book? Would a quarterback choose a playbook with just a few plays? Some coders feel that programming with Go is like coding with one hand tied behind their back. The language lacks all the cleverness other language designers have delivered to the world, and that’s a high price to pay.

Go doesn’t play favorites

The original developers wanted to create a small language, and they did so at the expense of many favorite features found in other languages. Go is a streamlined language. It does what you need but eschews the bells and whistles.

Why some love it: Many developers sing the praises of Go’s simplicity. Go doesn’t require them to gain or maintain expertise in dozens of features to be proficient. If they read through some code, they won’t be discovering constructs they’ve never seen before.

Why some hate it: Everyone has a few favorite features and tricks, but the odds are that Go doesn’t offer them. Developers sometimes complain that they could accomplish the same thing they could do in Go with just one line of COBOL or Java, or some other favorite language.

C-based syntax

Go’s creators have deep roots in the world of Unix, and it shows. The syntax is quite familiar to anyone who’s used C or any of the languages like Java or C# that borrowed from C. Go’s curly brackets and typing will be comfortable for this crew. The design team did remove some of the rough edges from traditional C, and simplify some of the details so it looks and feels more modern, but for the most part, Golang falls squarely in the tradition that began with C.

Why some love it: Programmers who grew up with the C style will intuitively understand much of Go. They’ll be able to learn the syntax very quickly and they can spend their time learning the few ways that Go cleaned up some of the annoying corners of C or Java. What’s not to love?

Why some hate it: In many ways, Python was designed to be the antithesis of C. There are no curly punctuation marks to delineate blocks of code and the typing is deliberately dynamic. Anyone who loves the Python approach will find plenty to dislike about Go. From this perspective, programming with Go feels like a step or three backward.

Go has (too) many rules

From the beginning, Go’s creators wanted to define not just the syntax but also much of the style and usage patterns of the language. They produced, for instance, a standard formatting library to discourage battles over the right way to indent Go code. They’ve curated lists of idioms and encouraged programmers to use the best ones. They’ve also explicitly banned some habits that are merely frowned upon by other languages, like unused variables or cyclic dependencies. Go’s build process is programmed to halt when it discovers these elements in the codebase.

Why some love it: Go’s strongly idiomatic rules ensure code will be easier to grok. Teams will have fewer fights over style because there are fewer options or reasons to evolve their own personal style.

Why some hate it: All these extra rules and conventions feel like a straightjacket. Why is an unused variable a problem? If the compiler can detect it, the compiler can strip it out without bugging me. Is it so bad for programmers to have a bit of freedom in their life?

Go has extra error handling

Much of modern programming includes building in extra paths for code to take when errors appear. The code runs normally until something goes wrong. When an error happens, it must recover. It might just pause a bit, or it could completely give up. Building automated systems requires the introspection to know when things are working or failing.

Go takes a novel approach by encouraging programmers to write two pathways into the same function. Good Go code spells out both the normal approach and what should happen when an error arises. Go programmers like to say that “errors are regular values” because they’re part of the same code. There’s even a separate type system for errors that allows programmers to create more specific forms of errors, then spell out how they should be handled.

Why some love it: The Go approach acknowledges that errors exist and encourages the programmer to make a plan for handling them. This encourages programmers to plan ahead and build in the kind of resilience that makes for better software.

Why some hate it: Unnecessary error handling makes Go functions fatter and harder to understand. Often, every function in a deep chain must include similar code that’s doing more or less the same thing with the same error. Other languages like Java or Python encourage programmers to “throw” the errors up the chain to a specific block that will “catch” them, which can result in cleaner code.

The standard library

It’s not just Go’s syntax that’s designed to be a simple but powerful standard that unites teams. The standard library includes support for many of the major tasks that are common for web-based microservices programming. The input and output routines begin with low-level network packet juggling and handle all the tasks of increasing complexity like handling the HTTPS protocol or decoding JSON data. Setting up a full web server only takes a few lines of code because it’s all included in the “net/http” part of the library.

Why some love it: When many of the standard features are handled by the default library, most code is easier to read because no one is writing their own version or arguing about which package or third-party library is better.

Why some hate it: It’s hard to complain about such a nice pile of code, but curmudgeons like to point out that competition is a good indicator of demand and innovation. The fact that some languages support multiple packages tackling the same task indicates a deep interest and a rich culture.

The executable size

One of the goals for the Go team was to make it easy to deploy Go programs and they accomplished this by bundling together everything into one executable. Everything is ready to run because all of Go’s library routines are included in the standard build.

Over the years, developers who don’t like executables that are dozens or even hundreds of megabytes in size have found ways to strip out the unnecessary parts. It’s a bit more work to set the right flags and include extra steps in the build process, but it can be done.

Why some love it: Disk space is cheap. Deploying code in strange locations can be a nightmare when different versions of libraries are installed. Go developers save us huge amounts of time by just building one executable file.

Why some hate it: How many copies of the Go libraries are on my disk? If I have 100 programs, that means 100 copies. At some point, efficiency is a consideration. Yes, disk space is cheaper than ever, but memory bandwidth and caching continue to be primary issues for execution speed.

Big daddy Google

Golang was developed at Google and the big company continues to be one of its major supporters, shipping the compiler and much of the toolchain. There is some support from outside Google like GopherJS, a transpiler that turns Go into JavaScript. But for the most part, much of the Go development effort comes directly from inside Google.

Why some love it: A great deal of the work today involves writing code for the constellations of servers and clients, the same kind that is such a big part of Google’s workload. If Go is good for Google, it’s also good for those of us who are working in the same way. If Google engineers built something they would love, anyone with similar projects is going to love it just as much. 

Why some hate it: It’s not that people don’t like Google per se, it’s just that programmers distrust centralized authorities. Problems like vendor lockin and lack of control are serious issues for anyone trying to curate a tech stack. All of Google’s generosity still leaves programmers leery, especially when other language choices have large, open source communities built around them.