Do or Not Do, There Is No Try() – InApps 2022

As Golang observer Matt Klein recently remarked, the Go community is again experiencing a bit of a “kerfuffle” over a proposed new feature. In case you weren’t sure, a “kerfuffle” is defined as “a commotion or fuss, especially one caused by conflicting views” and it’s a perfectly appropriate assessment of what’s going on, but… isn’t that exactly to be expected?

Not to focus on the kerfuffle point for much longer, but it is a word we’ve often used here to describe the toiling of the open source communities building languages like Go and Rust and wanted to briefly point out its tendency not to over-dramatize what is happening. There is disagreement and conflicting views, but working through those views is how the open source sausage is made, is it not?

Of course, in the Go community, how the core team receives those opposing views may be a point of soreness among some who vehemently opposed the vgo package versioning for Go and felt that, in the end, it was rammed through despite their objections. As one Gopher points out, it is better to debate now than summarily accept and then later deprecate.

Well, as Go makes its way to Go 2.0, with Go 1.14 currently taking center stage for debate, there is, again, as Klein points out, some kerfuffle about a newly proposed feature called try(), which is “designed specifically to eliminate the boilerplate if statements typically associated with error handling in Go.”

According to the proposal, the “minimal approach addresses most common scenarios while adding very little complexity to the language” and “is easy to explain, straightforward to implement, orthogonal to other language constructs, and fully backward-compatible” as well as extensible for future needs.

Much of the disagreement around try() comes in the form of whether or not the resultant code is more or less readable than current implementations of error handling. Beyond that, however, some say that even if try() were accepted, it has faults that would prevent them from recommending or even allowing its use among their teams.

Meanwhile, another point of contention is offered in an open letter to the Go team about try by William Kennedy who often writes about Go, and focuses on not style or function, but rather whether or not a solution is needed at all. According to Kennedy, “the perceived error handling complaints are perhaps overblown and these changes are not what the majority of Go developers want or need” and that try() may be a solution searching for a problem, and even the cause of more problems than it solves.

“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,” Kennedy writes.

He goes on to point out those very sensitivities that may have lingered from previous discussions in the Go community:

“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 judgments on priorities.”

A quick perusal of the /r/Golang thread on the topic arrives at little in the way of support for try(), with a number of commenters pointing out its “magical” and opaque nature. All that said, perhaps this is just a case of a vocal minority, because if the words of Klein are to be taken as any indication, try() could be destined for acceptance. Is this simply another tale in the nature of Go as an open source language driven by a core team that won’t take objections from the community to heart? Or is it much ado about nothing?

We’ll have to keep an eye on Go as it continues to grow to make that determination. For now, we’ll take a look at…well, there’s no real news in the world of programming so much this week, so here are a few interesting links we found in our perusal nonetheless.

This Week in Programming

• The Art of Language Detection: GitHub offers a look at the machine learning based classification of programming languages — a subject near and dear to a company that plays host to over 300 different programming languages — and unveils “a machine learning classifier named OctoLingua based on an Artificial Neural Network (ANN) architecture which can handle language predictions in tricky scenarios.” Unfortunately, they write, the tool they normally use called Linguist often fails to identify code when presented without file name extensions or in snippets. With OctoLingua, the team hopes to “provide a service that enables robust and reliable source code language detection at multiple levels of granularity, from file level or snippet level to potentially line-level language detection and classification.”

• Deep Learning Containerized: Containers keep delivering on their core value proposition, this time in the form of containerized deep learning stacks from Google, which the company released to beta this week as a way to make it even easier for developers to get up and running with machine learning. The containers are “pre-packaged, performance-optimized, and compatibility-tested” and provide “a consistent environment for testing and deploying your application across GCP products and services, like Cloud AI Platform Notebooks and Google Kubernetes Engine (GKE), making it easy to scale in the cloud or shift across on-prem.”

• The Source Available Future: If you’ve been paying any attention to the open source world as of late, than you’ve heard about another controversy — “kerfuffle” may not apply here — about open source licensing and the tendency for big cloud providers to offer open source software as a service, thereby taking all the business from those who may have developed the software in the first place. Well, if you aren’t familiar with that tale, than take a gander over at Stephen O’Grady’s synopsis of the tale in his piece “Cockroach and the Source Available Future” which takes you through the entire saga.

Featured image by Michelle Maher.