←back to thread

Go subtleties

(harrisoncramer.me)
235 points darccio | 1 comments | 13 Oct 25 07:42 UTC | HN request time: 0.388s | source
Show context
rowanseymour ◴[22 Oct 25 08:27 UTC] No.45666258[source]▶
Ah the old nil values boxed into non-nil interfaces. Even after 8 years writing go code almost every day this still bites me occasionally. I've never seen code that actually uses this. I understand why it is the way it is but I hate it.
replies(4): >>45666614 #>>45666792 #>>45666859 #>>45669163 #
kitd ◴[22 Oct 25 09:55 UTC] No.45666859[source]▶
The advice I've read (and follow) is always to return values, not interfaces, from functions and test for nil against them. That IME tends to nip the majority of nil interface problems in the bud.
replies(4): >>45667017 #>>45667105 #>>45667244 #>>45667694 #
rowanseymour ◴[22 Oct 25 10:50 UTC] No.45667244[source]▶
That works until 1) you don't want to export the value types 2) the return values aren't simple structs but slices or maps because []x is not a []X even if x implements X.
replies(2): >>45667431 #>>45667624 #
1. formerly_proven ◴[22 Oct 25 11:20 UTC] No.45667431[source]▶
> the return values aren't simple structs but slices or maps because []x is not a []X even if x implements X.

I assume this is because on is an array of struct pointers and the other is an array of fat pointers, since Go has reified interfaces (unlike higher-level languages).