*context* I've been working full time in Go at an org with > 1000 engineers for the past 2 years, and I've read The Go Programming Language cover to cover. So I'm a decent gopher by most standards. I pretty much only _pass_ pointers when mutability of the original object is desirable. I _use_ pointers in structs when a value is optional, eg. when parsing from json. Objects like slices and maps are *no more efficient to pass to as a pointer than by value*, since the "value" of a slice/map is a "header" struct with a 3 fields denoting length, capacity, and a pointer to the first address of the slice. So there's already a pointer under the hood, no need to create another. Also, pass-by-value is typically faster for small things. And if you're running on 64 bit hardware and you're passing pointers to < 64 bit variables like int32, you're literally using twice as much space to pass that as a pointer than you would to just copy the 32 bit value, since a pointer will be full word, or 64 bits on that architecture.
This is why I think mixed API isn’t a strong con. It may be warranted for performance, and doesn’t strike me as very different from simply returning different types.
Yeah, gotta consider the overhead of the GC having to perform escape analysis on pointers. Most cases copying is faster simply because the value is just on the stack and is easily cleaned up when the function returns.
🔥I use pointers to: 👉 `mutate` data between 2 isolated `code blocks (functions)` 👉 Avoid new memory allocations 👉 make the Garbage Collector happy ... Thank you for the great video !
Whenever you return an invalid value from a function, either nil or an uninitialized struct, it's good to include an extra bool (or error) return as well. For example: func f() (*MyStruct, bool) { if !somePrecondition() { return nil, false } return &MyStruct{}, true } This greatly reduces the chance that the caller will forget to check for nil, and get a nil pointer dereference. This comes from the builtin map type, and the _, ok := pattern.
I'm learning Go and for now I'm returning in every function I have, but I watched a bunch of videos that recommend if I'm getting info and I won't do any change in the state the function should not return a pointer. I'll give a try for this approach and see what happens
I tend not to use pointers when it’s record type values. For example user. A lot of the times it’s coming out of a context and I need that to be a real val
Using pointers should be an intentional and deliberate action. If you are not sure, don’t use it until you are. I’ve seen plenty projects where EVERY struct is a pointer and it sucks big time.
What do you think about filling up DB with values instead of nil? I've been bitten by this before where a nil db field could not be scanned into a struct field. It was a runtime error.
I used to think that the pointer in GoLang was an advantage over other languages, but now, after your video, I understand that we have different opinions about the pointer.
![BabyChiefDoit - Too Slow (feat. STAR BANDZ) [Official Music Video]](http://i.ytimg.com/vi/zayaxws7RPg/mqdefault.jpg)
I hope you all enjoy this video! Let me know what you think in the comments
*context* I've been working full time in Go at an org with > 1000 engineers for the past 2 years, and I've read The Go Programming Language cover to cover. So I'm a decent gopher by most standards.
I pretty much only _pass_ pointers when mutability of the original object is desirable. I _use_ pointers in structs when a value is optional, eg. when parsing from json. Objects like slices and maps are *no more efficient to pass to as a pointer than by value*, since the "value" of a slice/map is a "header" struct with a 3 fields denoting length, capacity, and a pointer to the first address of the slice. So there's already a pointer under the hood, no need to create another. Also, pass-by-value is typically faster for small things. And if you're running on 64 bit hardware and you're passing pointers to < 64 bit variables like int32, you're literally using twice as much space to pass that as a pointer than you would to just copy the 32 bit value, since a pointer will be full word, or 64 bits on that architecture.
I think that for us Go noobs some code examples illustrating these points would be hugely benefitial
True
Copying a struct is much faster than messing with pointers, unless it is a huge struct
Yep. If its a huge struct then copying becomes inefficient
This is why I think mixed API isn’t a strong con. It may be warranted for performance, and doesn’t strike me as very different from simply returning different types.
Yeah, gotta consider the overhead of the GC having to perform escape analysis on pointers. Most cases copying is faster simply because the value is just on the stack and is easily cleaned up when the function returns.
🔥I use pointers to:
👉 `mutate` data between 2 isolated `code blocks (functions)`
👉 Avoid new memory allocations
👉 make the Garbage Collector happy ...
Thank you for the great video !
Actually heap pointer is bad for GC
Nice work!
Whenever you return an invalid value from a function, either nil or an uninitialized struct, it's good to include an extra bool (or error) return as well. For example:
func f() (*MyStruct, bool) {
if !somePrecondition() {
return nil, false
}
return &MyStruct{}, true
}
This greatly reduces the chance that the caller will forget to check for nil, and get a nil pointer dereference. This comes from the builtin map type, and the _, ok := pattern.
OOOO
This is awesome.
And if you want to return an error, would you just append it?
thanks, makes sense
2 More pros:
- Can use methods with both pointer and value receivers.
- Does not copy the sync.Mutex
Aye awesome thank you
Most of the downsides appear to just be skill issues
Everything is a skill issue if you break it down
@@MelkeyDev Fair enough, great video by the way.
I'm learning Go and for now I'm returning in every function I have, but I watched a bunch of videos that recommend if I'm getting info and I won't do any change in the state the function should not return a pointer.
I'll give a try for this approach and see what happens
I think thats a good rule of thumb.
In all honestly, on smaller scale apps, either approach will be good
use pointers in C 🚫
use pointers in go ✅
Great video! Personally I’m purely in the “pointer for mutability only” camp. I default to copies so I can’t mutate things on accident.
Hell yeah. Love it
I tend not to use pointers when it’s record type values. For example user. A lot of the times it’s coming out of a context and I need that to be a real val
Using pointers should be an intentional and deliberate action. If you are not sure, don’t use it until you are.
I’ve seen plenty projects where EVERY struct is a pointer and it sucks big time.
Could you point me to the nearest grocery store using golang?
yea
How are mutability and nil as value good things?
Great video
Please make a video how to avoid memory leaks!
What do you think about filling up DB with values instead of nil? I've been bitten by this before where a nil db field could not be scanned into a struct field. It was a runtime error.
Once spent like an hour getting nil pointer deference when working w redis only to realize that I forgot to initialize the struct😭😔
Classic.
I used to think that the pointer in GoLang was an advantage over other languages, but now, after your video, I understand that we have different opinions about the pointer.
thats good yeah??
@@MelkeyDev Yep))))
Great vide Melkey, I understand more about pointers in Go awesome language!!
I started learning GO, a few months ago. How we can structure our codes to prevent import cycle errors
Nah always give the shit struct back and an error
return a stack pointer is just weird
its all weird
I only use pointers when i purposelly want to modify the struct somewhere.
Hey @MelkeyDev do you have any suggestion for a book/course/any other resource to learn computer science concepts in Go?
ruclips.net/video/qT14b1pxtiI/видео.html&t I made this video - let me know if its helpfu