←back to thread

Go subtleties

(harrisoncramer.me)
234 points darccio | 4 comments | 13 Oct 25 07:42 UTC | HN request time: 0.637s | 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 #
1. 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 #
2. 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).

3. bpicolo ◴[22 Oct 25 11:43 UTC] No.45667624[source]▶
For 1/, you can return a struct value type without exporting it. If it satisfies the receiving interface they won’t have a problem.

That’s exactly the pattern I use for most Go development

replies(1): >>45672442 #
4. kbolino ◴[22 Oct 25 17:34 UTC] No.45672442[source]▶
This affects discoverability, though. Your unexported type won't have public documentation. So you end up having to publish an interface anyway (even if you don't return it) or document in words what the method set looks like.