4 ms·

I like Go, but my main annoyance is deciding when to use a pointer or not use a pointer as variable/receiver/argument. And if its an interface variable, it has

I like Go, but my main annoyance is deciding when to use a pointer or not use a pointer as variable/receiver/argument. And if its an interface variable, it has a pointer to the concrete instance in the interface 'struct'. Some things are canonically passed as pointers like contexts. It just feels sloppy and I'm worried I'm going to make a mistake.

empath75 1y ago
Using pointers as optional types is the absolute worst part of using go.
vbezhenar 1y ago
Just use pointers everywhere? Who cares.
- softwaredoug 1y ago
  But just not a pointer to an interface. Its annoying to need to think about whether I’m working with an interface type of concrete type. And if use pointers everywhere, why not make it the default?
grey-area 1y ago
I just always use pointers for structs.
- nikolayasdf123 1y ago
  I 80% of time use structs. common misunderstanding: it does not reduce performance for pointer vs value receivers (Go compiler generates same code for both, no copy of struct receiver happens). most of structs are small anyways, safe to copy. Go also automatically translates value receivers and pointer receivers back-and-forth. and if I see pointer I see something that can be mutated (or very large). in fact, if I see a pointer, I think "here we go.. will it be mutated?". written 400,000 LOC in Go, rarely seeing this issue.
spicyusername 1y ago
...do you want a copy or the original object?
- tgv 1y ago
  Yup, that's it. If you're going to modify a field in the receiver, or want to pass a field by reference, you're going to need a pointer. Otherwise, a value will do, unless ... that weird interface thing makes you. I guess that's the problem?
RadiozRadioz 1y ago
This confused me too. It is tricky because sometimes it's more performant to copy the data rather than use a pointer, and there's not a clear boundary as to when that is the case. The advice I was given was "profile your code and make your decision data-driven". That didn't make me happy. Now I always use pointers consistently for the readability.
aatd86 1y ago
I mostly use it as a signal for mutability to some extent. And also when I want a value with stable identity I'd use a pointer.
looshch 1y ago
> my main annoyance is deciding when to use a pointer or not use a pointer as variable/receiver/argument i think you can take these[1][2][3][4] official advices and extrapolate to other cases [1] https://go.dev/wiki/CodeReviewComments#receiver-type https://go.dev/wiki/CodeReviewComments#receiver-type [2] https://google.github.io/styleguide/go/decisions#receiver-type https://google.github.io/styleguide/go/decisions#receiver-ty... [3] https://go.dev/doc/effective_go#pointers_vs_values https://go.dev/doc/effective_go#pointers_vs_values [4] https://go.dev/doc/faq#methods_on_values_or_pointers https://go.dev/doc/faq#methods_on_values_or_pointers

empath75 1y ago

Using pointers as optional types is the absolute worst part of using go.

vbezhenar 1y ago

Just use pointers everywhere? Who cares.

softwaredoug 1y ago
But just not a pointer to an interface. Its annoying to need to think about whether I’m working with an interface type of concrete type. And if use pointers everywhere, why not make it the default?

grey-area 1y ago

I just always use pointers for structs.

nikolayasdf123 1y ago
I 80% of time use structs. common misunderstanding: it does not reduce performance for pointer vs value receivers (Go compiler generates same code for both, no copy of struct receiver happens). most of structs are small anyways, safe to copy. Go also automatically translates value receivers and pointer receivers back-and-forth. and if I see pointer I see something that can be mutated (or very large). in fact, if I see a pointer, I think "here we go.. will it be mutated?". written 400,000 LOC in Go, rarely seeing this issue.

spicyusername 1y ago

...do you want a copy or the original object?

tgv 1y ago
Yup, that's it. If you're going to modify a field in the receiver, or want to pass a field by reference, you're going to need a pointer. Otherwise, a value will do, unless ... that weird interface thing makes you. I guess that's the problem?

RadiozRadioz 1y ago

This confused me too. It is tricky because sometimes it's more performant to copy the data rather than use a pointer, and there's not a clear boundary as to when that is the case. The advice I was given was "profile your code and make your decision data-driven". That didn't make me happy. Now I always use pointers consistently for the readability.

aatd86 1y ago

I mostly use it as a signal for mutability to some extent. And also when I want a value with stable identity I'd use a pointer.

looshch 1y ago

> my main annoyance is deciding when to use a pointer or not use a pointer as variable/receiver/argument i think you can take these[1][2][3][4] official advices and extrapolate to other cases [1] https://go.dev/wiki/CodeReviewComments#receiver-type https://go.dev/wiki/CodeReviewComments#receiver-type [2] https://google.github.io/styleguide/go/decisions#receiver-type https://google.github.io/styleguide/go/decisions#receiver-ty... [3] https://go.dev/doc/effective_go#pointers_vs_values https://go.dev/doc/effective_go#pointers_vs_values [4] https://go.dev/doc/faq#methods_on_values_or_pointers https://go.dev/doc/faq#methods_on_values_or_pointers