I very much like Go's simplicity, but nils are terrible. Pointers carry 3 different intents that are not encoded in the code:
- Optionality
- Mutability
- Memory optimisation
I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value.
Sometimes the intent is not clear and you are forced to check nullity everywhere. An Option type fixes this but it's not idiomatic Go code and forces to wrap every thing you call
In a previous job our unhinged devs decided that optionality was defined by golangs default value for primitives (empty string, 0, false, etc) simply because they didn't want to put pointers everywhere.
So the JSON APIs would accept nulls or absent keys when sending data to the API. But when retrieving it we would get golang default values for those keys. And, of course, the backend code was full of == 0, == "", == false...