If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times.
Now repeat this for thousands of Go projects.
Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.
Obviously, it would be better if Go didn't have this problem. If I made Go 2, it would have blank interface be "none" and blank pointer be "null". Even better, I would add a reference type that can't be null and sum types or something like that. But these things are all relative.
In Python, people using "is" for numbers is a problem. But in practice only very junior developers do that and it mostly gets caught in dev. There was the Digg outage caused by a default argument being [] instead of None https://lethain.com/digg-v4/ and that I see as a slightly more serious bug that can slip by without good code review.
Every language has pitfalls and the question is whether they outweigh the other benefits.
Yes, in my case anyway. That code didn't have any unit tests around it. Goland didn't flag it. It's a pattern that was "surprising" to me at least. Particularly since it breaks with tradition.
I consider Goland to be invaluable when coding go. But still, it's not perfect.
> There was the Digg outage caused by a default argument being [] instead of None
FWIW Pycharm flags this now, and can fix this automatically. Not sure about VSCode.
I guess the point I'm making is IDE's should find the novice mistakes, and then a lot of my complaints about languages go away.