Comment by dilap

Yeah, I totally agree -- given Go's design, the behavior makes sense (and changing the behavior just to make it more familiar to users of languages that fundamentally work differently would be silly).

However, the non-intuitive punning of nil is unfortunate.

I'm not sure what the ideal design would be.

Perhaps just making an interface not comparable to nil, but instead something like `unset`.

  type Cat struct {}
  type Animal interface{} 
  
  func main() {
   var c *Cat = nil
   var a Animal = c 
   if a == nil { // compile error, can't compare interface to nil
    ;
   }
   if a == unset { // false, hopefully intuitively
   }
  }
    

Still, it's a sharp edge you hit once and then understand. I am surprised people get so bothered by it...it's not like something that impairs your use of the language once you're proficient.

(E.g. complaints about nil existing at all, or error handling, are much more relatable!)