Go pain-point #1: Shadowing
result, result_str, result_str_str…
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 GetProcess returns 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 output_str , output2 , and output2_str . Oh, and Rust too!
