3 ms·

Nil pointers are #1 on that list. Tony Hoare called them a "billion dollar mistake"[1]. In fact, Go made nil pointers even worse, since nil may not be nil: htt

Nil pointers are #1 on that list. Tony Hoare called them a "billion dollar mistake"[1]. In fact, Go made nil pointers even worse, since nil may not be nil: http://play.golang.org/p/fIde3QZt9m 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.

deleted 14y ago
[deleted]
vanderZwan 14y ago
> 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.
- blablabla123 14y ago
  How is this more consistent? This can produce nil pointer dereferences.
  - vanderZwan 14y ago
    > 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. https://groups.google.com/forum/?fromgroups=#!searchin/golang-nuts/calling$20methods/golang-nuts/wcrZ3P1zeAk/WI88iQgFMvwJ https://groups.google.com/forum/?fromgroups=#!searchin/golan...
blablabla123 14y ago
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.

deleted 14y ago

[deleted]

vanderZwan 14y ago

> 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.

blablabla123 14y ago
How is this more consistent? This can produce nil pointer dereferences.
- vanderZwan 14y ago
  > 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. https://groups.google.com/forum/?fromgroups=#!searchin/golang-nuts/calling$20methods/golang-nuts/wcrZ3P1zeAk/WI88iQgFMvwJ https://groups.google.com/forum/?fromgroups=#!searchin/golan...

blablabla123 14y ago

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.