Go is still not good

Recently I was in a meeting where we were considering adopting Go more widely for our backend services, but a couple of the architect level guys brought up the two-types-of-nil issue and ultimately shot it down. I feel like they were being a little dramatic about it, but it is startling to me that its 2025 and the team still has not fixed it. If the only thing you value in language design is never breaking existing code, even if by any definition that existing code is already broken, eventually the only thing using your language will be existing code.

This has already been explained many times, but it's so much fun I'll do it again. :-)

So: The way Go presents it is confusing, but this behavior makes sense, is correct, will never be changed, and is undoubtedly depended on by correct programs.

The confusing thing for people use to C++ or C# or Java or Python or most other languages is that in Go nil is a perfectly valid pointer receiver for a method to have. The method resolution lookup happens statically at compile time, and as long as the method doesn't try to deref the pointer, all good.

It still works if you assign to an interface.

  package main
  
  import "fmt"
  
  type Dog struct {}
  type Cat struct {}
  
  type Animal interface {
   MakeNoise()
  }
  
  func (*Dog) MakeNoise() { fmt.Println("bark") }
  func (*Cat) MakeNoise() { fmt.Println("meow") }
  
  func main() {
   var d *Dog = nil
   var c *Cat = nil
   var i Animal = d
   var j Animal = c
   d.MakeNoise()
   c.MakeNoise()
   i.MakeNoise()
   j.MakeNoise()
  }

This will print

  bark
  meow
  bark
  meow

But the interface method lookup can't happen at compile time. So the interface value is actually a pair -- the pointer to the type, and the instance value. The type is not nil, hence the interface value is something like (&Cat,nil) and (&Dog,nil) in each case, which is not the interface zero value, which is (nil, nil).

But it's super confusing because Go type cooerces a nil struct value to a non-nil (&type, nil) interface value. There's probably some naming or syntax way to make this clearer.

But the behavior is completely reasonable.

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.