>Shadowing I'd assume is "solved" with warnings (as errors)?
Yep, shadowing variables are caught by the linters built into every golang package for major editors. Using these linters is built into the culture and as a result they tend to crop up less than you think for such a glaringly obvious issue.
>I don't know enough Go to know how you'd effectively avoid the non-nil interface to nil instance issue, short of carefully checking for nil on every conversion.
You let it panic. This is a programming error, which is what panics are for. If you caught the error, the proper thing to do would be call panic manually.
>As for the for loop scopes, do you just declare new variables in the local scopes? Interestingly, I expected the "WRONG" behavior in 2 of the 3 for loop examples... and C# actually changed their behavior (in C#5?) from "WRONG" to "OK" with for-each loops.
This is subjective, and easily testable. Most early Go developers learn to test their understanding of "for loop scoping" after they implement an infinite loop that expects `defer f.Close()` to close the resource, but instead it builds up until the kernel kills the process for not releasing file descriptors.
---
I was recently surprised to find out that `type MyError error` and switching on types like `switch variable.(type)` can be a bit scary [0]. Basically you should always define your new error type from a string and never attempt to re-use the builtin error type. In retrospect it makes sense, but you'd naively think this is the proper way to create a new error type.
I don't consider the linters enough to defend against shadowing - on Kubernetes we find one or two err shadowing bugs a month (https://github.com/kubernetes/kubernetes/search?p=1&q=shadow... is just the ones for a trivial search) that can sometimes be quite serious (I fixed one last week that leaked scheduler workers - https://github.com/kubernetes/kubernetes/pull/32643). Being extremely strict on shadowing has helped some, but it also leads to code which looks non-idiomatic and is slightly worse to read and review.
Taking address of a loop variable has also come up several times, although linters have many fewer false positives there.
Yep, shadowing variables are caught by the linters built into every golang package for major editors. Using these linters is built into the culture and as a result they tend to crop up less than you think for such a glaringly obvious issue.
>I don't know enough Go to know how you'd effectively avoid the non-nil interface to nil instance issue, short of carefully checking for nil on every conversion.
You let it panic. This is a programming error, which is what panics are for. If you caught the error, the proper thing to do would be call panic manually.
>As for the for loop scopes, do you just declare new variables in the local scopes? Interestingly, I expected the "WRONG" behavior in 2 of the 3 for loop examples... and C# actually changed their behavior (in C#5?) from "WRONG" to "OK" with for-each loops.
This is subjective, and easily testable. Most early Go developers learn to test their understanding of "for loop scoping" after they implement an infinite loop that expects `defer f.Close()` to close the resource, but instead it builds up until the kernel kills the process for not releasing file descriptors.
---
I was recently surprised to find out that `type MyError error` and switching on types like `switch variable.(type)` can be a bit scary [0]. Basically you should always define your new error type from a string and never attempt to re-use the builtin error type. In retrospect it makes sense, but you'd naively think this is the proper way to create a new error type.
[0]: https://play.golang.org/p/3BSKu8Cd4o