Learning Golang (some rough notes) - S01E01 - Pointers
Tags: go, learning
Published: 2020-06-29 11:29:46

---
title: Learning Golang (some rough notes) - S01E01 - Pointers
published: true
date: 2020-06-25 00:00:00 UTC
series: Learning Go
tags: go, learning
canonical_url: https://rmoff.net/2020/06/25/learning-golang-some-rough-notes-s01e01-pointers/
---


👉 [A Tour of Go : Pointers](https://tour.golang.org/moretypes/1)

I’ve never used pointers before. Found plenty of good resources about **what** they are, e.g.

- [https://www.callicoder.com/golang-pointers/](https://www.callicoder.com/golang-pointers/)

- [https://dave.cheney.net/2017/04/26/understand-go-pointers-in-less-than-800-words-or-your-money-back](https://dave.cheney.net/2017/04/26/understand-go-pointers-in-less-than-800-words-or-your-money-back)

But **why**? It’s like explaining patiently to someone that 2+2 = 4, without really explaining **why** would we want to add two numbers together in the first place.

(side note: I bet a ton of devrel material could be made more accessible by addressing the huge number of assumptions that are made, explicit and implicit, in explanations given)

My colleague Ricardo Ferreira gave me this great explanation:

> Pointers in Go has to do with three main things:
> 
> 1. 
> 
> Garbage Collection
> 
> Go is a garbage collected language just like Java. However, it uses of some less sophisticated algorithms to reclaim memory space than Java that tries to figure out too much doing heap transverse and thus spending too much CPU on it. Go is meant to provide better performance and because of this it tries to share the responsibility with the developer about how to track references. And if a developer uses a pointer; it is the indication about which references need to be reclaimed given its scope. It uses something called reference counting to figure that out.
> 
> 2. 
> 
> Encapsulation (Information Hiding)
> 
> Pointers are particularly good for structs, which represents complex data structures. By returning structs rather than the actual value developers can ensure that only the function that created the struct can act upon it.
> 
> 3. 
> 
> Immutability
> 
> You better than anyone will understand this. Structs represents records and therefore their occurance needs to be immutable. You can’t change what happened in the past and thus; you are not supposed to change structs — unless the function that created the struct provides a write operation. So in Go, we use the concept of interface methods that are nothing more than function pointers to a struct.

I also got some useful feedback from people on Twitter:

> Pointers in Go.  
>   
> I grok \*what\* they are and \*how\* to use them ([https://t.co/0nMV16r0Wz](https://t.co/0nMV16r0Wz) sorted me out there) - but can a kind soul point me to a good resource that explains \*why\* I would use them? Why don't I just pass variables around instead?
> 
> — Robin Moffatt 🍻🏃🥓 (@rmoff) [June 24, 2020](https://twitter.com/rmoff/status/1275777088268709889?ref_src=twsrc%5Etfw)

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

> Pointers are just indirection. For size, think of loading GB of data. Without indirection, you'd have to copy all of it every time. Pointer lets you say "here's where to find the data" rather than "here's a copy of the data".
> 
> — ewencp (@ewencp) [June 24, 2020](https://twitter.com/ewencp/status/1275842242972803072?ref_src=twsrc%5Etfw)

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

> The main reason is performance and memory management. Say you have a large complex object that you want to use as a parameter to a method. If you don't use a pointer then the entire object is copied and the copy is fed into the method. This means allocating and configuring a ...
> 
> — Ray Skywalker (@RaySaltrelli) [June 24, 2020](https://twitter.com/RaySaltrelli/status/1275833679412068352?ref_src=twsrc%5Etfw)

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>