I really wish nil didn't exist in Go. It causes those familiar runtime panics like "cannot __ on nil" we love from those loose scripting languages like node.
Nil values could be kind of tolerable if the language was always explicit about what is nillable and what is not. If you see something like "MyStruct" you can never be sure if it's an interface (can be nil) or a value (cannot be nil).
I understand the ambiguity you're talking about here, but how often does this actually bite you in practice? There are other context cues that you're dealing with a struct and not an interface, and the nil-ness of a return value isn't how you idiomatically communicate success or failure, even for things like map lookups where it would be somewhat natural in a C API to do that.
Zero values are one of the tenets of Go. It's like saying I which Go had exceptions which is to say you'd prefer not-Go. Ironically Go was promoted as the anti-Java which we know is littered with NPEs.
