Comment by ncruces

1 day ago

The underlying reason, which you hint on, is that in Go (unlike Python, Java, C#… even C++) the “type” of an “object” is not stored alongside the object.

A struct{a, b int32} takes 8 bytes of memory. It doesn't use any extra bytes to “know” its type, to point to a vtable of “methods,” to store a lock, or any other object “header.”

Dynamic dispatch in Go uses interfaces which are fat pointers that store the both type and a pointer to an object.

With this design it's only natural that you can have nil pointers, nil interfaces (no type and no pointer), and typed interfaces to a nil pointer.

This may be a bad design decision, it may be confusing. It's the reason why data races can corrupt memory.

But saying, as the author, “The reason for the difference boils down to again, not thinking, just typing” is just lazy.

Just as lazy as it is arguing Go is bad for portability.

I've written Go code that uses syscalls extensively and runs in two dozen different platforms, and found it far more sensible than the C approach.

1 comment

ncruces

dilap 1 day ago

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!)