Hardly a contrived problem, since I know of at least one occurrence where I had issues in production because of it. It was not error handling that was the probl

Hardly a contrived problem, since I know of at least one occurrence where I had issues in production because of it. It was not error handling that was the problem, which is exposed here. The problem was that I had a variable of an interface type and in the code was producing different objects implementing that interface. Now, a nil value was also allowed if none of the cases matched and then the variable was stored in a sync.Map as a value. The problem was that when retriving the value the nil check never matched. Why? Well, it's type is defined as the interface even if it doesn't point to any implementation. I get that the designers might not have considered a different option: it is allowed to invoke a method on a nil object, making what some languages would call static methods. Still, I agree with the grandparent: I think this is Go's biggest flaw, simply because it is so surprising.