► 33% OFF on my Go + HTMX + Templ Course PRESALE bit.ly/3UFruxO ► Join my Discord community for free education discord.com/invite/Ac7CWREe58 ► Exclusive Lessons, Mentorship, And Videos www.patreon.com/anthonygg_ ► 60% OFF on my Golang course fulltimegodev.com Thanks for watching
@destinlee6 ай бұрын
hahaha. Rule of thumb: If you don't need a pointer don't use a f**king pointer!! Locked in. Love it
@dineshsilwal96876 ай бұрын
Good stuff, Anthony. I was following the correct approach in my codebase. I see my collegues using pointer even in get apis which is no need and i have been correctly then frequently
@vitiok786 ай бұрын
I even think that if your project doesn't take millions of requests a second then you can try to write only pure functions that don't mutate their arguments. That InsertUser function could return a fresh copy of the User with a different age
@KevinONeillPlus6 ай бұрын
I tend to use pointers for services and values for, ahem, values. One thing that caught me out in the early days was that if you call a function that returns an interface, and you happened to get a “nil” value back, you can check the value for nil and it’s all good, but try and access something on the value and boom, nil pointer error.
@vitiok786 ай бұрын
Excellent point about using pointers only when it's really necessary. I used them everywhere trying to "save performance". It was so stupid... Even if it is a struct you won't have a huge performance difference between copying a pointer vs copying a struct.
@Laflamablanca9696 ай бұрын
I guess the only counter argument I’d have to trying to avoid returning pointers, is I’d rather the error fail spectacularly than silently. It’s much easier to detect an issue if it’s loud as opposed to erroring silently and using the default value. I guess it really just comes down to experience when writing code that utilises pointers
@anthonygg_6 ай бұрын
True
@christ.49776 ай бұрын
I'm not a programmer but I want to learn go. This is great content!
@vasanthkorada48026 ай бұрын
Thanks. need more videos like these
@davidhinojosa36806 ай бұрын
Good stuff, Anthony. We should really avoid using pointers in our own packages when starting, and only start adding them when we need some optimization
@krispekla6 ай бұрын
Returning pointers isn't a bad thing if you know what you are doing. One case when I use them is in storage/db/repo layer when I query db and create new struct where I map result. It is important to understand what happens under the hood. If I would return just struct, go compiler would then copy this struct I created and create new one that it would return and then deallocate first one. Other way around with pointer, pointer would be created on heap, just passed back up and later be ready for GC. Now imagine that your structs are big this would mean it would take more from your processing power/compute.
@mihneabuzatu7846 ай бұрын
Returning a structure from a function is just a move operation and is very fast. This is because allocating and deallocating from the stack is very fast, and modern processors are very good at memory copying. You would need to have very large structs (200+ bytes) to maybe see a performance increase (considering heap allocation + cache miss). This is the kind of optimization which you should benchmark first.
@krispekla6 ай бұрын
@@mihneabuzatu784 Interesting to know!
@jmatya6 ай бұрын
Hey, good video, what I'd like to get some insights (old programmer new on golang) is when to embedded structs by refs in struct rather than struct by values
@lancemax8576 ай бұрын
One way I know when to use and not to use pointer is based on how I want a variable to be treated. If I want a variable to be treated like an immutable variable then I would not use pointer, if I want to treat a variable like a mutable object and allows functions to change the values then I would use pointers.
@beck47156 ай бұрын
I made a "HashPassword" function that returned a pointer to a string before I knew better 😂
@Dave.Wattz1006 ай бұрын
Sometimes I am fetching something from the database, but in case of no records, I don't want error to be raised, therefore it is better to define method in a way that it returns pointer to the (let's say) user. By doing so, I can further in the code check if user != nil if I need it. I think this is more convenient than defining a method in a way that it returns a value and then if user is not found, ignoring that specific error. I think so because with using pointers, code is more neat. Yes it produces a risk of getting a panic, but that's a skill issue if you ask me. Please correct me if I am speaking nonsense.
@roy_c6 ай бұрын
You could create a sentinel error like ErrUserNotFound or similar and handle with errors.Is. I think is more expressive.
@MatheusSantos-gy5pi6 ай бұрын
In this case a return the struct and if the id is 0 i know that i didn't find any data. I don't know if it's correct, i started now to learn go
@EduarteBDO6 ай бұрын
@@MatheusSantos-gy5pi checking if id is 0 it's a pretty obscure way to handle it. Only you will know how to handle it, and you could forget about that. Or forget to handle the id == 0. Returning a error it's more expressive
@MatheusSantos-gy5pi6 ай бұрын
@@EduarteBDO So, how do i handle when it is a error from db and when is a error when i dont find a specific user for example?
@WiecejNoxiego6 ай бұрын
@@MatheusSantos-gy5pi You switch on the error type.
@serhat45716 ай бұрын
What's your theme for vs code?
@anthonygg_6 ай бұрын
Gruvbox
@AminShahbaghi5 ай бұрын
Thanks
@damien3096 ай бұрын
The whole pointer vs value debate is useless when it comes to performance. Don’t optimise in the dark or based on assumptions, the only right way to optimise is by profiling the app