What's the Point?

Information, examples, and tips about Pointers in Golang

Sean Kelly


Who am I?

I work for Tapjoy

I am a core mainter of:

Buffstreams : Streaming Protocol Buffers over TCP

Moldova : Randomized templated data

Chore : Tapjoys Job System in Ruby


What are they?

What benefits do they have?

When to use them?

When not to use them?

If you've used Pointers in other languages before...

Some of this might bore you

I don't have any ground breaking revelations about Pointers

This talk is to introduce the basics in Go

However, since this is all anyone cares about anyways...

My opinion is to use Pointer receivers on your methods by default

Have a safe trip home!

What are Pointers?

Pointers are a lot like "regular" variables

You can use them like a variable to call methods or properties of a value

You can pass them to functions

They get garbage collected

But each one of these things is a little different

Zero Values

Declaring Pointers : Incorrectly

Declaring Pointers : Correctly

Passing Pointers

Structs are passed as values

Everyone gets their own copy of the value in memory

Pointers act as references*

Everyone shares a reference back to the same place in memory

Remember: If the value inside the Pointer isn't threadsafe, you need to protect it!

Hauling Garbage

Golang uses a 3-color, Mark and Sweep GC. Once something cannot be "colored", it's considered out of scope

Normally, variables are collected once they fall out of scope

The memory addressed by a Pointer can be shared over many scopes

The memory addressed by a Pointer is only collected once it falls out of all scopes

Making a Point

Interesting Fact: Anything you can create with make, is automatically treated like a Pointer

... Even if you didn't use make to create it

Making a Point

Tips on using Pointers

Including everyones favorite question

Receiving Pointers

Should I use a Pointer or a Value as a method receiver?

Pointers, in most cases

Typically, you want to be using Pointers where possible

Additionally, you want to watch out for "Accidental Copying" when not using Pointers


Never use an interface as Pointer. It's technically already one

Interfaces are actually 2 pieces of data working in tandem:

The first points to memory address holding the underlying type

The second points to the actual value in memory

So, you never want to do this: f := func(i *MyInterface){}

But, you can totally do this: f(&S{})

That's because both S and *S adhere to the definition of MyInterface


The most common mistake people make when serializing (ex: JSON)

If a field can be null, you must declare it as a Pointer type

Otherwise, Golang will fill missing data in with a value-based Zero Value

There are similar concerns at play in other Serializations as well (ex: SQL)

Custom Pointer Types

Technically, you can declare a type as Pointer of an existing type

Example: type PointS *S

Important note: With few exceptions, there is no type-aliasing in Golang. This is a brand new type

Should you declare types this way?

My opinion is probably not

It's less clear to the reader, and it's easy enough to use custom types as Pointers already

Pointing to Pointers

You can declare Pointers to Pointers

If you've shared a Pointer P to a particular value, and wish to change the memory address it points to, not the value inside the address...

You'd use a Pointer to a Pointer

This is because many concurrent users of the Pointer would have copies of it which still point to the original place in memory

Pointing to Pointers

This means passing around Pointers is actually copying the Pointer (but not the value it points to)

A Pointer itself is actually a kind of (and passed by) value! (Remember my asterisk from before?)

Therefore, passing around a Pointer to a Pointer lets you swap in different Pointers simply

This, like other shared state, is not thread safe

Quick Example 1 : Structs

Quick Example 2 : Slices

Quick Example 3 : More Slices

Quick Example 4 : Also Slices


Pointers can be used mostly like regular variables

Go ahead and declare those method receivers on Pointer

You don't want to use Interfaces as Pointers, but using them with Pointers is fine

Serializing data? Remember your Pointers if fields can be null

Sharing References == Sharing State == Threadsafety Concerns

Pointers to Pointers are a little heady, but very important when needed

Bonus Slide: Terrible, Terrible Puns

My wife really, really wanted me to add puns like these to my talk:

I'm going to give you some "pointers" tonight

Here are some "tips" to help you stay "sharp" with pointers

I hope I've made my "point"

"This talk was so great, it's inspired me to new heights!" ~ Georges Seurat



What's the Point?

Information, examples, and tips about Pointers in Golang

Sean Kelly


Dave Cheney : http://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t

Steve Francia (sp13): http://spf13.com/post/go-pointers-vs-references