Was Go's Try Proposal a False Flag?

Earlier this week a Go proposal to add a new try built-in function was rolled back:

Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.

Proposal: A built-in Go error check function, "try"

The proposal would've added a special function used like this:

f := try(os.Open(filename))

As opposed to:

f, err := os.Open(filename)
if err != nil {
    return err
}

Despite the aformentioned overwhelming outcry, I think for most people this came as a big surprise. Everyone just assumed the feature was going to be added and there wasn’t anything anyone could do about it. Just take a listen to this gotime podcast:

So why did people feel this way?

An Unfortunate History

Go doesn’t have the best track record when it comes to working with the community on new features. You can see an early example of this when type aliasing was added to the language:

But the quintessential example is the move to Go modules.

In 2017 the Go dep project was started as an "official experiment" to provide a new solution to package management. It proceeded for a year or so largely with the work of Sam Boyer and other folks who had previously built Go package management tools like Glide. Though it had many practical problems (ie performance), I think it’s fair to say that the general understanding of the Go community was that dep was the future.

Then Russ Cox wrote vgo, a wholesale departure from the existing tool and before you knew it, seemingly out of nowhere, vgo became go mod, and that was that. It seemed like years of community engagement were tossed out the window. Russ even admitted as much:

We let Dep go its own way and end up somewhere unacceptable, making Go modules seem a very large course correction. Worse, the course correction surprised a lot of people, because we'd only shared concerns with the package management group.

I thought I could focus on the technical details and let the pkg mgmt group run community interactions. Somehow that led to the entire community believing that Dep was the official endgame, even though my discussions with the pkg mgmt group were clear it was not on that track.

Mind you vgo has turned out to be technically better, but the point is Google burned a whole lot of goodwill with the way the whole process played out. Folks felt betrayed and they no longer had a say in something that they had invested so much time and energy working on. Everyone expected any future involvement to inevitably end up vgo'd when some previously unknown Google solution would find its way through the backdoor.

Go 2.0

With that history in mind, let's turn our attention to the Go 2 Draft Designs on error handling, error values and generics. Go has received heavy criticism for its lack of features, particularly around generics, and the inability to make progress on that front represents something of an existential threat to the future of the language. I'm sure the folks managing the project feel that pressure but it puts them in a bit of a tough position.

On the one hand they need to placate the apparent programming masses who are frustrated with Go's lack of features. But on the other hand there is a quite vocal contingent of Go advocates who actually like Go's minimalism and are concerned that substantial changes to the language will destroy what makes Go special.

So what do you do?

The False Flag

You run a false flag. You create a proposal that introduces a new feature which makes a sweeping change to one of the core elements of the language. Then at the last minute you kill the proposal.

And what did that accomplish?

1. You demonstrated your willingness to make changes to the language. Even though the proposal didn't go through, everyone realizes that you're quite serious about making these sorts of changes. Generics will actually happen in Go and it's just a matter of time before they do.

2. You avoided making a change to the language which would've violated one of its core principles:

   Why does Go not have exceptions?

   We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

   Despite its verbosity, error handling in Go does have positive side effects, namely developers have to give some though with what to do with errors. The try proposal undermined that principle for what appeared to be very little gain. (and notice that naming it try was a brilliant move... no matter what it did, people were going to push back merely from the naming of it)

3. And finally, and most importantly, you've demonstrated that you do listen to the community. The try proposal wasn't vgo'd through and the feedback developers provide is taken seriously.

To salvage their relationship with the community the Go team had to kill a feature moments before being adopted. The try proposal was the the scapegoat that carried the sins of vgo into the wilderness -- the necessary false flag used to lower inhibition for future, much more significant changes.

It all makes perfect sense.

😈 I don't actually believe it was a false flag... but you've gotta admit the story fits surprisingly well.