Pointers — sharing a value without pointer arithmetic

In Go, passing a value to a function passes a copy of it by default — changes made inside the function don't affect the original:

A pointer is a value that holds the memory address of another value, letting a function reach back and modify the original instead of a copy:

The same symbol doing two related but different jobs (declaring a pointer type vs. dereferencing one) is a real, common point of confusion the first time — reading *int as a type declaration and *n as "go look at what this points to" are the two contexts to keep straight.

Languages like C allow pointer arithmetic — adding a number directly to a pointer to move to a different memory address, walking through raw memory by hand. Go's pointers can't do this in ordinary code; a Go pointer can only be dereferenced or reassigned to point somewhere else, never shifted by an arbitrary offset (the one escape hatch is the deliberately named unsafe package, which exists for low-level work and is a red flag anywhere else). This is a deliberate safety trade-off, matching this domain's "why Go" theme from lesson 1 — most of the practical value of pointers (letting a function modify a caller's data, avoiding an expensive copy of a large struct) doesn't actually require arithmetic on addresses, and removing it eliminates an entire, historically serious class of memory bugs.

Recognizing *T as "a pointer to T" and knowing when Go implicitly uses pointers for you (methods on a struct, covered in the structs/composition lesson, commonly use a pointer receiver specifically so they can modify the struct) is essential to reading real Go code — a function signature taking *User instead of User is communicating, right there in the type, that it intends to read or modify the actual value the caller passed in, not just look at a copy.