Well, I agree with almost all that you have said here but I feel that there is a really important aspect which was missed here, which is regarding how the variables get allocated on the stack vs the heap and how the garbage collection in Go works ..
hey, isn't there another use case for pointers which is passing a WaitGroup to a goroutine? if a pointer is not passed, then goroutines will have their own copies of the WaitGroup and the main goroutine won't be notified when they're done executing
Wouldn't pointers come in handy when dealing with bigger data? Instead of copying the entire thing over and over again, you would work with its pointer, and let the GC do its job once at the end.
Would have been cooler if you had shown the assembly difference between the pointer version and the non pointer version to show the extra overhead that go has to do
Sadly that is outside the scope of a "basics" style video. I am actually working on a concurrency tutorial that will cover how to do performance testing, since it's a fairly advanced topic I feel comfortable tossing that in there.
It’s also important to keep in mind that data accessed via a pointer is more likely to be allocated on the heap, so you’ll have to pay the garbage collector for it’s job … Copying and clearing small values may be cheaper than paying the garbage collector.
One of the best explantation for pointer usage i managed to find. Thank you! Would you agree with my takeaway : "I shouldnt pass immutable objects almost exlusively as ref as to not create garbage"?
Sure! Golang has a garbage collector where objects and variables are automatically deallocated when they go out of scope. By passing a pointer, the garbage collector has to do some special magic that takes the allocated memory off the stack and onto the heap. It takes more time to do this than to make copies of that object.
this video kinda confused me, my question would be if i have a large lists with data that I want to modify or go through in a seperat function, would you really want to pass copy to the function or just pass a pointer. Also I really would be interested in the behavior of the pointers when passed to go routines (had a lot of issues with that)
No, you would handler it with a pointer receiver, the problem with passing by value is that you can never transition to pointer semantics. Essentially you need to verify what is a reader and what is a writer func, then use receivers with pointers or by value. (t Thing) is syntactic sugar essentially because it's passing the structure into the func already. It was created to alleviate extra args, using "this", and other roundabout ways to express ownership of the func. The classic way is to force a struct/class to implement an interface, but the Go team didn't want that so we have receivers.
Bool 3 values ? What are you talking about 😂 you just assigned a var named bool to nil, that’s not a third value for bool type. It’s just a variable assignment. Go is not changing Boolean algebra dude
why would you use a pointer to a bool to represent a tribool - this the most wasteful reason to allocate, seems odd in a video tellling you to avoid heap allocations
Wouldn't pointers be useful whenever you dont need to return and use the heap? Also get a new keyboard those switches are some of the scrachiest I've ever heard lol. Make sure it's hotswappable.
I'd suggest looking into sync pools if you're interested in efficiently allocating memory for objects, I have a video on that planned when I get time. Also, I like my keyboard, so no.
Well, I agree with almost all that you have said here but I feel that there is a really important aspect which was missed here, which is regarding how the variables get allocated on the stack vs the heap and how the garbage collection in Go works ..
Fantastic stuff! I don't know much about garbage collection in general, so this video was well explained
hey, isn't there another use case for pointers which is passing a WaitGroup to a goroutine? if a pointer is not passed, then goroutines will have their own copies of the WaitGroup and the main goroutine won't be notified when they're done executing
Yes! I need to update this video...
Wouldn't pointers come in handy when dealing with bigger data? Instead of copying the entire thing over and over again, you would work with its pointer, and let the GC do its job once at the end.
Nice, are you a Senior Dev?
Like to see more videos from you.
You didn’t assign the ID when you created the Thing. You just returned an empty Thing.
Is that what you meant to do?
Would have been cooler if you had shown the assembly difference between the pointer version and the non pointer version to show the extra overhead that go has to do
Sadly that is outside the scope of a "basics" style video. I am actually working on a concurrency tutorial that will cover how to do performance testing, since it's a fairly advanced topic I feel comfortable tossing that in there.
It’s also important to keep in mind that data accessed via a pointer is more likely to be allocated on the heap, so you’ll have to pay the garbage collector for it’s job …
Copying and clearing small values may be cheaper than paying the garbage collector.
One of the best explantation for pointer usage i managed to find. Thank you!
Would you agree with my takeaway : "I shouldnt pass immutable objects almost exlusively as ref as to not create garbage"?
Can you refer or explain why it is more expensive to pass by pointer than by value?
Sure! Golang has a garbage collector where objects and variables are automatically deallocated when they go out of scope. By passing a pointer, the garbage collector has to do some special magic that takes the allocated memory off the stack and onto the heap. It takes more time to do this than to make copies of that object.
Gray text and black background on a small screen. I have zero idea how to watch whats going on in this video.
why do people use pointers variables in structs properties eg . type someStruct struct {
ID *int
}
The video is very informative, thanks for sharing.
this video kinda confused me, my question would be if i have a large lists with data that I want to modify or go through in a seperat function, would you really want to pass copy to the function or just pass a pointer. Also I really would be interested in the behavior of the pointers when passed to go routines (had a lot of issues with that)
No, you would handler it with a pointer receiver, the problem with passing by value is that you can never transition to pointer semantics. Essentially you need to verify what is a reader and what is a writer func, then use receivers with pointers or by value. (t Thing) is syntactic sugar essentially because it's passing the structure into the func already. It was created to alleviate extra args, using "this", and other roundabout ways to express ownership of the func. The classic way is to force a struct/class to implement an interface, but the Go team didn't want that so we have receivers.
@@kirkkennedylincoln thx, this cleared some things up for me
try zooming the editor next time.
Good video anyway :)
This was fantastic! Thanks.
Thanks a lot for explaining its use.
Do you have you dot files on github for vim?
I use neovim with the vim plugin manager, here's my config: github.com/irateswami/configs/blob/mbp/.config/nvim/init.vim
@@bryanenglish7841 Thank you! I've starred :)
Nice video on go!
Bool 3 values ? What are you talking about 😂 you just assigned a var named bool to nil, that’s not a third value for bool type. It’s just a variable assignment. Go is not changing Boolean algebra dude
Thanks for the input. Three states would've probably been a better way of putting it.
cool informative video, nice work
great explain it should to be professional to learn this tutorial
totally lost and zoned out after first 5 mins
why would you use a pointer to a bool to represent a tribool - this the most wasteful reason to allocate, seems odd in a video tellling you to avoid heap allocations
It’s just information, do with it as you please
I really wanted to hear what you had to say on this subject but this video should have been 5 minutes
When You Should Actually Use Strings in Go. When You Should Actually Use ints in Go. When You Should Actually Use anything in Go.
annoying , cut it please (btw a loud keyboard and vimlike idee won't make anyone look smarter)
Ur mom liked it last night
Wouldn't pointers be useful whenever you dont need to return and use the heap?
Also get a new keyboard those switches are some of the scrachiest I've ever heard lol. Make sure it's hotswappable.
I'd suggest looking into sync pools if you're interested in efficiently allocating memory for objects, I have a video on that planned when I get time.
Also, I like my keyboard, so no.
What's the point of using a terminal instead of a IDE? You are just wasting more time
What was the point of you commenting? See, we could all be asking questions.