3 ms·
The explanation of the rationale for this method existing is a good primer on the footguns of go's "type system". It could be used, in my opinion, as a litmus
by ttymck 3y ago
The explanation of the rationale for this method existing is a good primer on the footguns of go's "type system".
It could be used, in my opinion, as a litmus test for go developers: if the explanation does not make complete sense to you, then you should think twice about implementing anything substantial (basically any use of interfaces or pointers) in golang (myself included)
- riwsky 3y agoany use of interfaces? No way, man. Any use of reflect? Sure.
- ttymck 3y agoYes, "nil interface vs nil value" is _eminently_ unintuitive and incredibly easy to get wrong: https://dev.to/mokiat/the-dark-side-of-go-interfaces-1541 https://dev.to/mokiat/the-dark-side-of-go-interfaces-1541
- earthboundkid 3y agoI dunno, ISTM it's like complaining that "0" != 0 in Go (it does in weakly typed languages like JS). A nil pointer and a nil interface are different types, and Go lets you call methods on nil pointers, so it would be weird if it treated nil pointers as special interface values.