Every interface is stored as a tuple of a type (pointer) and a value (pointer). The interface tuple returned by a() is ([]int, nil), comparing this to nil, which is a (nil,nil) returns false(!).
So, Go doesn't only have null pointers, it has null-pointers which sometimes has a 'hidden' type, which does not compare to the literal nil.
I like the language a lot but that is definitely a part that I dislike a lot. This doesn't feel consistent with the simplicity and obviousness of the rest of the language and it is error prone. Working full time with Go, it already happened 2 or 3 times this got me into an hour of debugging.
> The interface tuple returned by a() is ([]int, nil), comparing this to nil, which is a (nil,nil) returns false(!)
It's certainly a subtlety that can bite you, but I'd say that in this form it is arguably more consistent: assigning a type to an interface and having that be nil is not the same as assigning nil to an interface - those two variables are not equal and should be treated as such.
> those two variables are not equal and should be treated as such.
In that sense. Don't get me wrong: I'm not saying it fixes other problems with nill pointers, and yes, it introduces an extra possibility for dereference problems. Just like you're allowed to call methods on nill pointers if it's a nill pointer to a type that has these methods.
In fact, Go made nil pointers even worse, since nil may not be nil: http://play.golang.org/p/fIde3QZt9m
Every interface is stored as a tuple of a type (pointer) and a value (pointer). The interface tuple returned by a() is ([]int, nil), comparing this to nil, which is a (nil,nil) returns false(!).
So, Go doesn't only have null pointers, it has null-pointers which sometimes has a 'hidden' type, which does not compare to the literal nil.