[wwwigham]

Too bad nil/null _aren't_ typically bottom types or "base cases", but rather are real, runtime values that are sentinel values of some kind, rather than valid references to a value of some type. A distinct sentinel value that, for some usually historical reason, your compiler often thinks is OK to pretend is some interface, right up until it blows up at runtime. I get the confusion, though, since the same compilers that make that mistake often attribute some bottom-type-like characteristics to nil/null to facilitate using it (eg, considering it a valid possible value of all other expressable interfaces). Empty values and other sentinels are meaningfully different from a type-theoretic bottom type. Real bottom types don't come up much in mainstream languages - TypeScript has `never`, Scala has `Nothing`, and both typesystems have distinct representations of various `null`s and other empty values. Such uninhabitable bottom types see most of their use in describing generic constraints in situations where variance comes into play.

I think the real "WTF" here is that the go compiler quietly makes a simple `nil` written in your code into one of potentially many nil-like sentinels at runtime (contrary to what one may think), coerced depending on usage, and, moreover, that a simple `==` comparison or reflective call alone is insufficient to detect all of them. The semantics of how such a sentinel is coerced (and reflected) is surely in the realm of language esoterica and not simple beginner knowledge.