“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] (https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9)

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.

Sincerely,
William Kennedy