> I do think that its simplicity is the rejection of the idea that there are experts out there, and/or their relevance. It's not decisions based on knowledge and rejection, but of ignorance and "scoping out" of hard problems.
Ok, I'll ask the obvious question. Who are these experts and what languages have they designed?
> Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.
You're getting worked up about something that's hardly ever an issue in practice. I suspect that most of your criticisms are similar.
I think there's two layers to the typed vs. untyped nil issue (which is really about nil pointers in an interface value vs. the zero value of interface types).
The first is simple confusion, such as trying to handle "all nils" the same way. This is not necessary, though I have seen some developers coming from other languages get hung up on it. In my experience, the only real use for "typed nil" is reflection, and if you're using reflection, you should already know the language in and out.
However, the other aspect is that methods with pointer receivers on concrete types can have default behavior when the receiver is nil, while interfaces cannot. In the expression foo.Bar(), you can avoid a panic if foo is *T, but when foo is an interface, there is no way around the panic without checking foo's value explicitly first. Since nil is the default value of all interface types, even if you create a dummy/no-op implementation of the interface, you still risk nil panics. You can mitigate but never truly remove this risk.