new, make, and Choosing Allocation

You are writing a stack and want the first node without staging an empty struct somewhere:

type Node struct {
	Val  int
	Next *Node
}

func main() {
	head := new(Node) // *Node, pointing at a fully zeroed Node
	head.Val = 1
	head.Next = new(Node)
	head.Next.Val = 2
	// head: 1 -> 2 -> nil
}

new(T) does one thing: allocate storage for a T, zero it, and return a *T pointing at it. The zeroing is a guarantee, not a habit — every field gets its zero value (0, "", false, nil pointers), so head.Next starts nil and the list terminates correctly without an init step. This is the memory semantics C's malloc lacks: no uninitialized garbage, no field you forgot to set.

new and the address-of operator overlap heavily. These two lines produce equivalent results:

a := new(Player)
b := &Player{}    // same zeroed Player, one word pointer

// With initial values, only the literal form works directly:
c := &Player{Name: "mira", HP: 100}

The practical rule: reach for &T{...} whenever fields are known at construction — it reads as one statement and shows the values. new(T) earns its place when you need a zeroed pointer with no values yet, when the type is built by a helper that fills it in, or when generics force a type-only expression:

func zeroedPair[T any]() (*T, *T) {
	return new(T), new(T) // no literal syntax exists for an unknown T
}

Where new misleads is with types that are themselves references. new([]int) returns a *[]int — a valid pointer to a slice header that is nil. Nothing is broken; you simply got exactly what new promises (zeroed storage) when you wanted a ready-to-use slice, and the only way to write through it is (*s) = make([]int, 0, 8), a second allocation wrapped in a dereference. Slices, maps, and channels are the three types whose zero values are not fully initialized containers, and they have their own builtin for a reason — that builtin is make.

A slice, a map, and a channel are small headers pointing at runtime-managed structures: backing arrays, hash buckets, channel buffers and waiter queues. Their nil zero values are readable in limited ways, but usable containers need that machinery built — which is what make does, and why its first argument must be one of exactly three types:

ids := make([]int, 5)            // len 5, cap 5 — zeroed elements, real storage
hits := make(map[string]int, 64) // bucket table sized for ~64 entries
ch := make(chan int, 10)         // buffered channel, room for 10 sends

Each form initializes what its type needs beyond zeroing. The slice gets a header plus a backing array of the requested length and capacity. The map gets its bucket region pre-sized by the optional hint (so a fill loop starts ahead — Maps: Insert, Lookup, and Delete). The channel gets its buffer and synchronization state, none of which a zero value provides.

Contrast the same slice built three wrong ways:

a := new([]int)    // *[]int -> points at a nil slice: append needs (*a) = ...
var b []int        // nil slice: reads fine, but no reserved capacity
c := make([]int, 0, 8) // ready: len 0, cap 8, appends land in place

a compiles, dereferences cleanly, and still cannot serve as an initialized buffer — the pointer is correct and the container is absent. b is the legitimate zero value you use when growth is coming through appends anyway (Slice Basics and the Slice Header). c is the answer when you know you will fill it.

Two syntax facts settle the rest. make takes a type plus size arguments — make([]int, 0, 1024), make(map[string]bool), make(chan Job, 4) — while new takes a single type and no sizes at all; new([]int, 5) will not compile. And for channels, the length/capacity arguments are not cosmetic: a zero-capacity channel blocks every send until a receiver arrives, while capacity decouples the two (Channel Basics). When sizing looks like a performance tweak, it is usually a semantics decision wearing a performance costume.

Most allocation questions in everyday Go resolve in one of four columns:

Notice what is missing: allocations you never see. An int declared inside a function with its address never taken usually lives in a register or on the stack — no GC object, no free list, no cost worth optimizing away. The compiler decides placement by escape analysis: take an address or return a reference, and the value moves to the heap (Heap Escape Analysis). This reframes the choice — you are selecting semantics (zeroed pointer? initialized container? plain local?), and the allocator follows.

Three habits keep the table honest in real code:

Do not allocate to avoid a copy you have not measured. func heavy(cfg *Config) for a struct with five fields is premature indirection; the copy was a few words. Pointer parameters for large structs or mutation — not for time.Duration (Pointers as Function Parameters).

Reserve capacity where the final size is known.

ids := make([]int, 0, len(rows)) // one allocation for the whole fill
for _, r := range rows {
	ids = append(ids, r.ID) // never reallocates
}

Let the zero value do constructor work. bytes.Buffer, strings.Builder, and sync.Mutex are all usable from var b bytes.Buffer — no new, no make, no constructor. Types that cannot be (any struct holding a map field you write to) should own an explicit New... function (Nil Checks and Zero-Value Design). The table gives the syntax; the type's zero-value contract decides which row applies.