Subscribe to the Ardan Labs Insider

You’ll get our FREE Video Series & special offers on upcoming training events along with notifications on our latest blog posts.

Included in your subscription
  • Access to our free video previews
  • Updates on our latest blog posts
  • Discounts on upcoming events

Valid email required.

Submit failed. Try again or message us directly at

Thank You for Subscribing

Check your email for confirmation.

An Open Letter To The Go Team About Try

Author image
William Kennedy

“Once a language gets complex enough, programming in it is more like carving out a subset from an infinite sea of features, most of which we’ll never learn. Once a language feels infinite, the costs of adding further features to it are no longer apparent”. - Mark Miller

The new try proposal is an addition to the language that introduces a second mechanic to handle errors. It is being introduced in response to data gathered from the 2018 Go Survey and a review of proposals that were submitted during the Go 2 proposal process. The conclusion the Go team made from these data gathering exercises was that Go developers wanted better error handling.

If you look at this graph provided by the Go survey, you will see error handling lands at 5% for the biggest challenge faced by Go developers.

Figure 1

Based on this, I believe the perceived error handling complaints are perhaps overblown and these changes are not what the majority of Go developers want or need. The bias could stem from the fact, there is so little to complain about in Go, error handling would show up in any survey. If you look closely, error handling is not even in the top 3 challenges faced by developers, it’s number 5

I suggest the Go 2 proposal data is biased because only those who had a problem submitted proposals and this leaves out all of the developers who don’t consider error handling in Go needs to be better. The survey data probably isn’t much better at removing bias though it’s a more inclusive data set.

Rob Pike gave a talk last year at the Go Sydney meetup where he talked about the Go 2 changes. In his talk, he suggested that the use of if err != nil in code bases is nowhere near as common as the vocal minority suggest. Marcel van Lohuizen did a similar study and found that for code low on the stack (closer to main) if err != nil is not common, but it does become increasingly common if one moves higher up in the stack (closer to the network or operating system). That “plumbing code” tends to have a lot more checks but it’s possible to eliminate checks with good design. I think many of us who have been writing code in Go for a while can agree with that assessment.

I believe that it’s true that some portion of the Go community, via surveys and proposals, want improved error handling, but the mandate for try as an alternative for if err != nil is not supported by the data. I don’t believe it’s clear that the proposed try solution is the right design since it introduces two ways to do the same thing as it relates to the simple case when an error will only be propagated back up to the caller. Since this new mechanic is going to cause severe inconsistencies in code bases, disagreements on teams, and create an impossible task for product owners to enforce consistent guidelines, things need to be slowed down and more data needs to be gathered.

This is a serious change and it feels like it’s being pushed through without a concerted effort to understand exactly what those 5% of Go developers meant when they said they wanted improved error handling. I plead to the Go team to re-evaluate the data sets being used before the try error handling experiment finds itself in any version of the language. In Go’s history, once things are introduced as experimental they are never rolled back. I ask that more time is taken to gather data to determine the actual impact this change will have on code bases. Finally, priorities should be re-evaluated for Go 2 and the use of the Go 2 proposal data should not be used to make judgements on priorities.

William Kennedy

Go Training

We have taught Go to thousands of developers all around the world since 2014. There is no other company that has been doing it longer and our material has proven to help jump start developers 6 to 12 months ahead of their knowledge of Go. We know what knowledge developers need in order to be productive and efficient when writing software in Go.

Our classes are perfect for both experienced and beginning engineers. We start every class from the beginning and get very detailed about the internals, mechanics, specification, guidelines, best practices and design philosophies. We cover a lot about "if performance matters" with a focus on mechanical sympathy, data oriented design, decoupling and writing production software.

Capital One
Red Ventures

Interested in Ultimate Go Corporate Training and special pricing?

Let’s Talk Corporate Training!

Join Our Online
Education Program

Our courses have been designed from training over 30,000 engineers since 2013, and they go beyond just being a language course. Our goal is to challenge every student to think about what they are doing and why.