Go pain-point #1: Shadowing
I’ve been programming in Go again recently after a little hiatus and it has unfortunately brought to my attention the language’s lack of variable shadowing.
Variable shadowing is when you can redefine a variable in your scope and it allows you to do things such as:
“Get rid of the
var and just assign it,” say a million echoed voices from the depths of reanimated Google Groups. And, in this simple case, that would work! But if you’re ever dealing with an API, e.g. the AWS Textract API, you might want to use the variable
output after each call to a few different functions, each with very similar yet technically different return types. For example, the
StartProcess function might return
StartProcessResult and the next function
GetProcessResult. These two are mutually exclusive since, if you’re trying to get the result of the process, you must have already started it. This means that it’s perfectly safe to re-use the identifier since at any given point, only one binding will be valid. And yet, Go doesn’t allow for this like Rust does.
It might seem unsafe or in bad practice, but it’s actually a huge boon for writing idiomatic code not just in Rust, but in general. When I use some variable
output, no matter the language, it’s clear that I’m expecting the result from some operation. The emphasis is on my process, not the intricacies of the medium. But when I then have to declare my output variable as
output_str or, even worse,
output2, now the language itself is imposing its own rules onto my process. The emphasis is now on the context of the program, even if I am never going to use the first
output again! Why is it bad? Because the language said so. Not me!
Luckily, this could theoretically be added with backwards-compatibility if the Go team ever decides to grace us gracious little Gophers with such a blessing. In the meantime, hello
output2 , and
output2_str . Oh, and Rust too!