► 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

hahaha. Rule of thumb: If you don't need a pointer don't use a f**king pointer!! Locked in. Love it

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

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_

2 ай бұрын

True

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.

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.

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

Thanks. need more videos like these

I'm not a programmer but I want to learn go. This is great content!

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

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.

@mihneabuzatu784

2 ай бұрын

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.

@krispekla

2 ай бұрын

@@mihneabuzatu784 Interesting to know!

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

Thanks

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.

I made a "HashPassword" function that returned a pointer to a string before I knew better 😂

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

@anthonygg_

2 ай бұрын

Wise words.

What's your theme for vs code?

@anthonygg_

2 ай бұрын

Gruvbox

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_c

2 ай бұрын

You could create a sentinel error like ErrUserNotFound or similar and handle with errors.Is. I think is more expressive.

@MatheusSantos-gy5pi

2 ай бұрын

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

@EduarteBDO

2 ай бұрын

@@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-gy5pi

2 ай бұрын

@@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?

@WiecejNoxiego

2 ай бұрын

@@MatheusSantos-gy5pi You switch on the error type.

I use pointers by default, but I'm a bad man

HIM