Pros vs Cons of When to USE Pointers in Golang

if you've been learning go or if you've been reading go you probably have gone a few times where you've asked yourself should I be returning a pointer should I not be is it okay if this is a copy of the value does my function need to accept a pointer I don't really when should I use which and so that's what I want to talk about today so I was stumbling upon Reddit in r/ goang kind of my nesting Zone if you will and I came across a really cool post that says the following do you ever use pointers just for the sake of mil I've seen this in previous jobs whereby a function will pass/ return a pointer just s the function somewh can do if svar equals equals nil handle that logic instead of if svar equals equals some struck hand with some logic personally I don't like this approach but seems to be fairly prevalent amongst go code what are your thoughts on it you can see here one really good comment by I'm York sadly I do it all the time because I prefer accidentally der referencing a nil which shows up as an immediate error to accidentally working with an uninitialized struck which could cause any kind of sound issues further down line if only someone somewhere had invented a good way to return errors which prevented this kind of mistake haed Union Wikipedia link all of this is a pretty good topic to discuss about Pros versus cons returning pointers I'm guilty about this too I actually just taught a course on front of Masters about the differences of when to use a pointer as a return or not to use a pointer as a return so just a kind of brief uh summary you can pass values as go as copies or the act or the actual reference to memory it depends on the use case but obviously passing a copy to a function if you make any modifications to that structure that you're passing it's not going to only going to exist in the realm of that function whereas if you need to make a permanent change or actually change the address the reference in the struck then you have to pass in the pointer that references the allocated memory of that definition or wherever that's holding the the memory of the data field in the struck but it's a pretty interesting kind of topic when figuring out when should you use which for when so I decided to make this little Advanced board here of the pros in greed and the cons in red here of when returning pointers so the first one I want to say is kind of funny efficiency and I'm putting here because if you have let's say a very complex struck with tons of fields if you constantly passing the copy returning a pointer to an object instead of that copy can save memory and this is especially true for like I said large strs or objects in your go code if you're passing strs you know between functions or just across your application on the con side in that same topic is this could lead to memory leaks so what do I mean by this so if you have a pointer that is indefinitely referencing some object or some piece of memory you could run into memory leaks within your go application now I know the garbage collector does this Go's garbage collector is very crucial for this and probably saves a lot of people's keester however if you're not careful and you do not free up the memory of a pointer then you could run into some issues performance or even leaks down the line all right another good point to add in the pros column and I've already mentioned this is mutability so like I said if you're passing in the actual uh pointer of a struck with a bunch of different data fields if you make a modification you can mutate it unlike a copy where if you're passing in a copy of a struck and you make a modification and let's say you return the struck or whatever and you think that field has been updated and you reference it down your code you could run into some pretty nasty gotas so just passing in a pointer to your shuck allows you to mutate those fields in place and then you know you're free to do whatever you want with that modified struck but on the other side of that same argument this leads to safety concern and what do I mean by that if you don't want to actually modify the field in the data if you accidentally pass a pointer and you make a change that's mutable and you've actually modified the reference in that struck then you have basically unsafely modified a field in your struck so returning pointers can lead to unwanted modifications on the underlying data type if you're not careful and this is especially true if the color isn't aware that whether they're receiving or returning is a pointer so uh the big one the one that Sparks this whole video is uh return nil as value and this is extremely key especially if you kind of couple it with like the zero value of an error which is nil so you can basically say that you know if your function call returns in nil you can use it as an expectation upstream or Downstream wherever you kind of expect a return from a function that can either create a struct for you or you know do something else or you know even a better example if your code handles an error instead of returning you know struck like this along with your error you can just return nil and error which is a little bit nicer it makes the code a little bit easier to read I mean is it a big deal no because Upstream whoever's calling this function it's only going to care about the error it's going to say if error does not equal to nil however I do see kind of the convenience factor of having nil available for us to do any kind of you know comparison or just check if anything exists in that return alongside the error if you guys like go in this kind of content make sure you click subscribe button it does help the channel a lot a lot of effort goes into these videos and it truly is the best way to sub support if you enjoy but let's get back to the video okay now I don't have one that's necessarily coupled against the returning nil as uh as a pro however I quickly Googled one other con with this cuz I couldn't really think of many and there's actually something about concurrency so basically as it says when sharing pointers across go routines you must ensure proper synchronization to avoid a race condition this can complicate the design and implementation of concurrent systems so I think what this means is if you're passing pointers into different go routines and you make a modification to that strug maybe different places you may find yourself having race conditions or if you're making kind of any you know call on that struck that depends on the field to be modified on a previous synchronous or asynchronous flow you may get this kind of race condition so concurrency I think that's kind of maybe a knit but I think the race condition is definitely possible it's definitely something I could see happening uh with go routine and then last con I see is inconsistent AP API design so what I mean by this is a lot of sdks typically use one or the other so typically in any kind of library that you use they either expect uh references or they return pointers so it makes sense that if you are going to just use one keep a consistent across your entire application make sure you kind of consider all these other cons we've talked about here but don't kind of flop around the two don't make one function call in the same Library expect a pointer or return a Pointer while another one does not that could just make a bad user experience and I actually thought of another major one this kind of goes under the safety nil pointer D reference so this nil pointer D reference is talked about in this Reddit post you can catch it right away but if you have a method call on a field in your struck that just so happens to be nil you're going to get a panic and that's going to pretty much crash your entire app so that's another pretty nasty con again under safety that you should definitely consider when using or returning pointers in your application I actually think this is the biggest con I probably should have pointed higher but yeah I mean nil point of D reference this is a nasty one a lot of people have been bit by this the classic example is um you know if you're passing data between a database and it's not there or um if you have like a non initialized map Ino and you pass that down and then you call a method on it yeah that those are Nast if you know what I'm talking about leave me a comment below I'm curious to hear what you think all right but that's it for this video let me know what you guys think I found this Reddit post kind of interesting so I just want to quickly share my thoughts on it let me know in the comment section below if you can think of any more pros and cons I think this a pretty decent list let me know why do you use pointers and uh when do you choose to return a pointer or to not return a pointer definitely let me know in the comment section below and as always comment like And subscribe if you haven't come on let's get the 25k love you guys make sure you give me that PO catch you later [Music]

Channel: Melkey

Views: 9,794

Keywords: computer science, software engineer, computer programming, coding, learn to code, machine learning, artificial intelligence, cloud, python, javascript, how to code, go, golang, how to write http services in go, how to learn go, best resources to learn golang, how to get hired in tech with go, programming, software engineering, theprimetime, theprimeagen, fireship, web design, web development, programmer humor, c pointers, go pointers, pointers tutorial, low level learning

Id: UoQu9li3xK0

Length: 7min 53sec (473 seconds)

Published: Fri Apr 26 2024