It's true that explicit code is good, but "Go code reviews are a breeze" was not remotely my experience. For me and my past teams, reading through piles of boilerplate verbiage like this - among other 'explicit' syntax - was more of an impediment to understanding the flow of the program. Personally I think what the above commenter said is pretty much spot-on, and typical of Go teams I worked in.
I'd love to have a look at your code because this isn't my experience at all. What's your background ? What's your team background ? Are you writing go code with the mindset of a java/cpp/whatever dev ?
Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
> Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
A quick look around k8s certainly shows evidence of lots of boilerplate-y error handling.
To give my perspective, I come from a primarily python background, but have used C++ and JS enough to know my way around, and Java was what I primarily learned programming in.
I write relatively little go, but I review a fair amount of it. The people whose code I'm reviewing are competent, idiomatic go programmers who follow go's style guide (https://github.com/golang/go/wiki/CodeReviewComments) to the extent that it exists.
I find it far more difficult to tease out what a stanza of go is doing compared to an equivalent stanza of python due to the visual noise. In python (and other languages), I usually use a somewhat functional/declarative style, so I use abstractions like comprehensions and such to allow terse transformations of data.
Go doesn't have these. In essence, the tradeoff go makes is to not provide abstractions in the language. This forces users to recreate them[1] ad-hoc, or suffer without abstractions at all (which doesn't scale). This makes everyone suffer, instead of just people unfamiliar with the abstractions suffer.
But the flow of the program isn't only or primarily about the happy path. I find it annoying when languages that don't force explicit error handling choices, force me to go searching for the non-happy path. Where do they handle the errors at? It's nowhere in this pull request. Are there errors to handle? You have to assume there must be because exceptions. Then I have to write a bunch of comments asking if they know whether this line can throw or not. Usually the answer is "I don't know" and then I'm the annoying one in the PR review because I tell them to please find out and either add a comment or handle/wrap the exception appropriately.
If the only thing you care about is the happy path in your review then Go code will annoy you. But you are also only doing half of your job in that review.
In exception-safe code, you don't care if a particular statement can throw - if the code is correct today when some line can't throw, it should still be correct tomorrow when that line can throw.
Also, it's much easier to look for catch{} blocks than it is to look for Go code that actually handles errors, since code that forwards errors, code that wraps errors, and code that handles errors all looks more or less the same in Go (if err != nil {...}).
