In spite of my advanced years (I turn 63 in December) I do try to stay reasonably current while at the same time encouraging and supporting the younger generation. There are times, however, where I have to call bullshit on what is written by the youngsters.

I recently came across a BS article via the Hacker News app on my fabulous iPhone 6S+ titled “Golang landmines.” Hacker News is the Slashdot for the ADHD segment of today’s contemporary young white male twenty-something code slingers. HN is essentially a lot of links “curated” and presented in a very simplistic list on your device. I put the word “curated” in quotes because this article, like so many others I’ve encountered via HN, has weird error messages in the body of the article; when you see that, you know you have to follow the link to the original at the top of the article. Thus it was with this article.

As befits its contemporary hipness, this article is hosted on Github. It’s part of a Github conversation which I find rather amusing. I guess anywhere that will host content is a decent platform for publishing and the direct consumption of said publishing, even Github. Whatever… The “author” writes about three “easy to make mistakes” in Go. The problem is that those mistakes can be avoided by the Go tools if you’re half aware and actually pay attention to the warnings and error messages the Go compiler/interpreter emit with your code. For example, consider the following Go example.

package mainimport "fmt"func DoSomething(doit bool) (result string) {if doit {result := "doit is true"}return result}func main() {fmt.Printf(DoSomething(true) + "\n")}

This code snippet is a refinement of the “shadowing considered harmful to your sanity” example at the bottom of the article. The issue is the use of “:=” in line 7 instead of the regular assignment operator “=”. If you read the on-line documentation for Go (Short variable declarations) you’ll discover that “:=” is “shorthand for a regular variable declaration with initializer expressions but no types.” Further reading shows that:

Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original.

It isn’t like you haven’t been warned. With that in mind I don’t understand how that so-called code example worked in the first place. If you take my example above and save it in a file named “shadow.go” and either run it directly (go run …) or build it (go build …) you get the following error message:

./shadow.go:7: result declared and not used

at which point everything stops. Granted, it’s not the most helpful error message in the world, and the example from Github surely isn’t helpful in illustrating what’s wrong and where, but Go does attempt to keep you from doing The Wrong Thing, if obscurely. So my question stills stands; how did that code example in the Github article build or run to start with?

And my comment to the Go compiler team is; why in heaven’s name can’t you people come up with clearer error messages that reference the specific language violation you’re complaining about? A clear error message with a reference to the specification would be so much more helpful, especially to those starting to learn the language. I mean, Go is a fairly new language written by Google engineers who should know better.

That’s why the coding youngsters don’t want us old farts around. We point out their errors and in the process cause crippling embarrassment to the little snowflakes.

Update

I’ve been rather rudely asked what I would consider an “appropriate” Go error message. Here’s what my version of Go would emit with such an error:

./shadow.go:7: Use of short variable declaration hides 'result' first declared on line 5.

The error message is now more succinct as to where as well as why, tying directly back to the language specification. This helps aspiring Go programmers learn.