*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 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
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 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.
I think you are forced to use pointers when variables from a struct are optional, ex: an optional number field in a document of mongodb, if the number is zero you can't tell the difference if it's in the DB or if it was zero'd by the struct. But if you use a pointer you'll have nil if it's not in the db.
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
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.
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.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/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 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!
I think that for us Go noobs some code examples illustrating these points would be hugely benefitial
True
tbf, GPTs have you covered these days
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
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
Great vide Melkey, I understand more about pointers in Go awesome language!!
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.
2 More pros:
- Can use methods with both pointer and value receivers.
- Does not copy the sync.Mutex
Aye awesome thank you
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 started learning GO, a few months ago. How we can structure our codes to prevent import cycle errors
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))))
I think you are forced to use pointers when variables from a struct are optional, ex: an optional number field in a document of mongodb, if the number is zero you can't tell the difference if it's in the DB or if it was zero'd by the struct. But if you use a pointer you'll have nil if it's not in the db.
How are mutability and nil as value good things?
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
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.
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.
Please make a video how to avoid memory leaks!
Hey @MelkeyDev do you have any suggestion for a book/course/any other resource to learn computer science concepts in Go?
ua-cam.com/video/qT14b1pxtiI/v-deo.html&t I made this video - let me know if its helpfu
Could you point me to the nearest grocery store using golang?
yea
Great video
I only use pointers when i purposelly want to modify the struct somewhere.
use pointers in C 🚫
use pointers in go ✅
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.
return a stack pointer is just weird
its all weird
Nah always give the shit struct back and an error