So, we've been talking about deallocation, deallocating memory, and it can be hard to determine when it is appropriate to deallocate a variable. Reason is because you can only deallocate a variable when you know the variable is no longer in use. You don't want to deallocate a variable and then later need that variable that you deallocated, because then it's basically gone. So, it's hard sometimes to figure that out, figure out when it's not in use or when it is in use and so on. So, here's an example, a Go example. This is legal in Go but because this is a pain, his is not legal in certain other languages but in Go this is legal thing. If you look at the first function foo. Inside there we declare this variable x. So, It's a local variable to this function foo and what's returned though is the address of x, f say x, write a pointer to x. Now, then in the main function down below, the main function calls foo. Then, the main function, what happens is since it calls foo and it gets the return value of foo actually gets assigned to a variable in the main function. So, the trick here, the confusion here, is that this program foo normally, if you declare a local variable x when the function ends that variable x should be deallocated. Right. You're done with it because the function is done with it. But in this case it's not the case because is returning a pointer to x. So, now the main, since the main now has that pointed to x since that's getting returned to the main, the main might still use that pointer to x. So, you can't just say "foo is now done, I can get rid of its local variable x because maybe main is going to use that local variable because now main has a pointer to it". Okay. So, this is actually a legal thing to do in Go. So, this is just one example of how pointers especially make it difficult to tell when deallocation is legal and when it's not. So, deallocation is a complicated thing. So, what people do? One way of dealing with that is to have garbage collection. So, garbage collection is basically automatic or an automatic tool that deals with deallocation. So, this is part of interpreted languages and this is done by the interpreter, so if is, say Java, the Java Virtual Machine or a Python is a Python interpreter something like that. It keeps track of these pointers and it determines when a variable is not in use anymore and when it is. Once it determines that a variable is definitely not used, there no more pointers, no more references to that variable then the garbage collector deallocates it. Only when it all references are gone. So, this is nice, garbage collection is a nice thing. It's easy for the programmer. Right. Programmer doesn't have to worry about exactly when deallocation, when to do it, when not to do it. Believe me deallocating memory is a big headache, in other lang say C or something like that. But, it requires an interpreter so generally compiled languages like C, C++, they can't do it, but Go is different. Okay. Go is different and better in the sense. So, Go is a compiled language which has garbage collection built into it. So, that is a unique feature Go which is really nice. So as a result, the Go compiler can figure out when to follow these points is to some extent and figure out when this point you're still in use. It basically, keeps track we're not going to go into Go garbage collection because that is the complicated thing. There are many ways of doing it but generally you have to keep track of the pointers to a particular object. Once all the pointers are gone, then you know that the object can be deallocated. So, garbage collection in Go allows two things. One thing is, it will actually allocate stuff on the heap and the stack itself. So, you as a programmer don't have to determine, I want to put this on the heap I want to put this on the stack. The Go compiler, it'll put code in there at compile-time, it'll figure out this needs to go heap, this needs to go to the stack and it'll garbage collect appropriately. So, if it's on the heap it will garbage collected appropriately will see when all the pointers are gone and it'll determine when it can be deallocated. This is a really helpful thing. Now, there is a downside because the act of garbage collection does take some time. Right. So, there's a performance hit but it's a pretty efficient implementation and garbage collection is so darn useful is probably worth it to put it in Go. So, that's a trade-off that Go makes. It slows things down a little bit but it is a great advantage because it makes programming a lot easier. You don't have to go as far as using a full-on interpreter like you would in an interpreted language.
