DEV Community: Triệu Mẫn Trà

[Golang] Why Go Has Both `make` and `new`

Triệu Mẫn Trà — Mon, 05 Oct 2026 02:58:47 +0000

You want to create a slice:

numbers := make([]int, 3)

But for a struct, you might see:

user := new(User)

Both seem to "create" something.

So why does Go need two built-in functions?

The answer is that make and new solve two very different problems.

The Concept

The simplest distinction is:

new(T) gives you a pointer to the zero value of T
make(T, ...) initializes a slice, map, or channel so it can actually be used

new works with almost any type.

make works only with:

slice
map
channel

Their return values are also different.

p := new(int)

Here:

p // *int

But:

s := make([]int, 3)

Here:

s // []int

make does not return a pointer to the slice.

It returns the initialized slice value itself.

Why Isn't the Zero Value Enough?

For many Go types, the zero value is immediately useful.

For example:

var n int
fmt.Println(n) // 0

And:

var u User

already gives you a valid zero-valued User.

But slices, maps, and channels are special.

Their zero values are nil.

var s []int
var m map[string]int
var ch chan int

Conceptually:

s  = nil
m  = nil
ch = nil

Sometimes that is useful.

But often you need their internal runtime state initialized before doing real work.

That is what make is for.

Small Runnable Example

package main

import "fmt"

type User struct {
    Name string
}

func main() {
    n := new(int)
    fmt.Println(*n)

    user := new(User)
    fmt.Printf("%+v\n", *user)

    numbers := make([]int, 3)
    numbers[0] = 10
    fmt.Println(numbers)

    users := make(map[string]int)
    users["alice"] = 42
    fmt.Println(users)

    jobs := make(chan string, 1)
    jobs <- "send email"
    fmt.Println(<-jobs)
}

Run it with:

go run main.go

Output:

0
{Name:}
[10 0 0]
map[alice:42]
send email

Notice the difference.

new(int) returned an *int pointing to:

new(User) returned a *User pointing to:

User{}

But make initialized the internal structures needed by the slice, map, and channel.

What Actually Happens?

`new`

Consider:

p := new(int)

You can think of it approximately like this:

new(int)

    int value
   ┌─────┐
p ─►  0
   └─────┘

The expression returns:

*int

The value being pointed to is the zero value of int.

Similarly:

u := new(User)

gives you:

*User

whose value initially contains zero values for all its fields.

One important detail: new does not mean "allocate this on the heap."

The Go compiler performs escape analysis and decides whether the storage can remain on the stack or needs to escape to the heap.

So this:

new(User)

should not be interpreted as:

force heap allocation

`make`

Slices, maps, and channels require more initialization.

For example:

s := make([]int, 3, 5)

A slice is not the underlying array itself.

Conceptually, it contains something like:

slice
 ├── pointer ─────► underlying array
 ├── len = 3
 └── cap = 5

make creates the necessary state for that slice.

Similarly:

m := make(map[string]int)

initializes a map so entries can be added.

And:

ch := make(chan int, 10)

initializes a channel with a buffer capacity of 10.

This is why make exists specifically for these three built-in reference-like types.

A Common Mistake: `new(map[...])`

Suppose you want a map.

You might write:

users := new(map[string]int)

(*users)["alice"] = 42

It compiles.

But it panics:

panic: assignment to entry in nil map

Why?

Because:

new(map[string]int)

creates a pointer to a zero-valued map.

And the zero value of a map is:

nil

Conceptually:

users
  |
  v
┌─────────┐
│ nil map │
└─────────┘

The pointer exists.

The map itself still hasn't been initialized.

You could technically do this:

users := new(map[string]int)
*users = make(map[string]int)

(*users)["alice"] = 42

But that is unnecessarily complicated.

Just write:

users := make(map[string]int)
users["alice"] = 42

What About Slices?

Slices have an interesting difference.

A nil slice can still be used with append:

var numbers []int

numbers = append(numbers, 10)
numbers = append(numbers, 20)

fmt.Println(numbers)

This works.

So you do not always need:

make([]int, 0)

A nil slice is often perfectly idiomatic.

But make becomes useful when you already know the desired length or capacity.

For example:

items := make([]Item, 0, 100)

If you expect roughly 100 items, providing capacity can avoid some backing-array growth while appending.

Nil Maps and Nil Channels Behave Differently

The zero values of slices, maps, and channels are all nil, but they do not behave identically.

Nil slice

You can append:

var s []int
s = append(s, 1)

Valid.

Nil map

Reading is valid:

var m map[string]int

fmt.Println(m["missing"]) // 0

But writing panics:

m["key"] = 1

Nil channel

Sending or receiving on a nil channel blocks indefinitely:

var ch chan int

ch <- 1

The goroutine will block.

This is another reason initialization with make matters when you actually need to use maps or channels.

Practical Example

Imagine a small worker service.

You need:

configuration
a job queue
a cache

type Config struct {
    WorkerCount int
}

type Worker struct {
    config *Config
    jobs   chan string
    cache  map[string]string
}

func NewWorker() *Worker {
    return &Worker{
        config: &Config{
            WorkerCount: 4,
        },
        jobs:  make(chan string, 100),
        cache: make(map[string]string),
    }
}

Here, make is appropriate for:

jobs
cache

because the worker needs an initialized channel and map.

For the struct itself, Go code commonly uses:

&Worker{...}

instead of:

new(Worker)

because the composite literal allows fields to be initialized immediately.

When Should You Use `new`?

new is useful when you specifically need a pointer to a zero value.

For example:

timeout := new(int)

But in normal application code, it is often less common than newcomers expect.

For structs, this:

user := &User{}

is usually at least as clear as:

user := new(User)

And if fields need initialization:

user := &User{
    Name: "Alice",
}

is much more useful.

new becomes particularly convenient in generic code or situations where obtaining *T for an arbitrary type is useful.

When Should You Use `make`?

Use make when initializing:

[]T
map[K]V
chan T

Typical examples include:

users := make(map[string]User)

buffer := make([]byte, 4096)

jobs := make(chan Job, 100)

You do not need to call make automatically for every slice.

For example:

var results []Result
results = append(results, result)

is completely valid and idiomatic.

Use make when you actually need initialization parameters such as length, capacity, or channel buffering—or when a non-nil map/channel is required.

A Simple Mental Model

Think about the two functions this way:

new(T)
   |
   v
zero value of T
   |
   v
return *T

While:

make(slice/map/channel)
          |
          v
initialize runtime structure
          |
          v
return the value itself

So:

new(T)

is mostly about obtaining a pointer.

While:

make(...)

is about initializing Go's built-in slice, map, and channel data structures.

Takeaways

new(T) returns a *T pointing to the zero value of T.
make only works with slices, maps, and channels.
make returns the initialized value itself, not *T.
new(map[K]V) does not initialize the map; it gives you a pointer to a nil map.
In everyday Go code, &Struct{} is often more useful than new(Struct).

[Golang] Why Go Variables Have Zero Values Instead of Being Uninitialized

Triệu Mẫn Trà — Sun, 04 Oct 2026 08:18:58 +0000

Consider this Go program:

package main

import "fmt"

func main() {
    var count int
    var enabled bool
    var name string

    fmt.Println(count)
    fmt.Println(enabled)
    fmt.Println(name)
}

It prints:

0
false

We never assigned anything to these variables.

So why do they already have values?

Because in Go, a variable is never in an uninitialized state. If you don't provide an initial value, Go gives it the type's zero value.

This sounds like a small language feature, but it has a surprisingly large effect on how Go programs are designed.

What Is a Zero Value?

Every Go type has a default value called its zero value.

Some common examples are:

int        → 0
float64    → 0
bool       → false
string     → ""
pointer    → nil
slice      → nil
map        → nil
channel    → nil
interface  → nil
function   → nil

Structs are initialized recursively.

For example:

type User struct {
    Name   string
    Age    int
    Active bool
}

Then:

var user User

is effectively:

User{
    Name:   "",
    Age:    0,
    Active: false,
}

You don't need to initialize every field manually.

Small Runnable Example

Create main.go:

package main

import "fmt"

type User struct {
    Name   string
    Age    int
    Active bool
    Tags   []string
}

func main() {
    var user User

    fmt.Printf("%+v\n", user)

    fmt.Println(user.Name == "")
    fmt.Println(user.Age == 0)
    fmt.Println(user.Active == false)
    fmt.Println(user.Tags == nil)
}

Run:

go run main.go

Output:

{Name: Age:0 Active:false Tags:[]}
true
true
true
true

Notice something interesting about Tags.

Its zero value is nil.

fmt displays a nil slice as [], but:

user.Tags == nil

is still true.

What Actually Happens?

The important rule is simple:

Storage for a variable without an explicit initializer starts with the zero value of its type.

This behavior is guaranteed by the Go language.

Conceptually:

var n int

starts as:

n = 0

And:

var user User

starts roughly like:

user.Name = ""
user.Age = 0
user.Active = false
user.Tags = nil

The compiler and runtime do not need to literally generate those assignments one by one.

The exact implementation depends on where the variable lives and how the compiler optimizes the program.

What matters at the language level is that your Go code always observes the correct zero value.

Why Is This Useful?

One major benefit is deterministic state.

Imagine a language where:

var count int

could contain whatever bytes happened to exist in memory previously.

Then:

if count > 100 {
    // ...
}

could behave unpredictably.

You would have to remember to initialize everything before using it.

Go removes that entire category of state.

A variable begins with a predictable value.

memory allocated
      |
      v
known zero state
      |
      v
program modifies it

This simplifies reasoning about programs.

But Go takes the idea further.

Zero values often influence API design.

Zero Values Can Make Types Immediately Useful

Consider sync.Mutex:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var mu sync.Mutex

    mu.Lock()
    fmt.Println("locked")
    mu.Unlock()
}

There is no constructor:

mu := NewMutex()

The zero value of sync.Mutex is already ready to use.

The same idea appears in many standard-library types.

For example:

var buf bytes.Buffer

You can immediately do:

buf.WriteString("hello")

without calling something like:

buf := bytes.NewBuffer(...)

This leads to a useful Go design principle:

When practical, make the zero value of your type useful.

Designing Your Own Useful Zero Value

Suppose we create a counter:

type Counter struct {
    value int
}

func (c *Counter) Increment() {
    c.value++
}

func (c *Counter) Value() int {
    return c.value
}

Now this works immediately:

var counter Counter

counter.Increment()
counter.Increment()

fmt.Println(counter.Value())

Output:

We didn't need:

counter := NewCounter()

Because value naturally starting at 0 gives the type a meaningful initial state.

This makes APIs simpler.

Instead of:

counter := NewCounter(0)

users can simply write:

var counter Counter

Common Mistake: Zero Value Does Not Mean "Ready to Use"

A common misunderstanding is:

If every type has a zero value, every zero value must be usable.

That is not true.

Consider a map:

var users map[string]string

fmt.Println(users["alice"])

Reading from the nil map is valid.

But this:

users["alice"] = "Alice"

panics:

assignment to entry in nil map

You need to initialize it first:

users := make(map[string]string)
users["alice"] = "Alice"

Channels have another interesting zero-value behavior:

var ch chan int

Here:

ch == nil

is true.

Sending to or receiving from a nil channel does not panic.

Instead, it blocks forever.

Pointers also have a nil zero value:

var user *User

But:

fmt.Println(user.Name)

will panic because you're dereferencing a nil pointer.

So remember:

zero value
    ≠
always usable value

The zero value is guaranteed and predictable, but its behavior depends on the type.

Practical Example: Backend Configuration

Suppose a service keeps some runtime statistics:

type Stats struct {
    Requests int64
    Errors   int64
    Healthy  bool
}

Creating it requires nothing special:

var stats Stats

Initially:

Requests = 0
Errors   = 0
Healthy  = false

That can be exactly the state we want.

As requests arrive:

stats.Requests++

There is no need for:

stats.Requests = 0
stats.Errors = 0
stats.Healthy = false

Go already gives us that state.

This becomes especially useful with large structs containing counters, flags, slices, pointers, mutexes, and other components.

You only initialize values that genuinely need something different from their zero value.

When Should You Rely on Zero Values?

Rely on zero values when they naturally represent the initial state.

For example:

var attempts int
var finished bool
var lastError error

These states are intuitive:

attempts  → 0
finished  → false
lastError → nil

You can also design structs around this property.

Prefer:

type Metrics struct {
    Requests int64
    Errors   int64
}

where:

var metrics Metrics

already makes sense.

But don't force zero-value semantics when your type requires mandatory configuration.

For example:

type Client struct {
    baseURL string
}

If a client cannot function without a URL, allowing this:

var client Client

to appear valid may be misleading.

In that situation, a constructor can make more sense:

client := NewClient("https://api.example.com")

The goal isn't to eliminate constructors.

The goal is to make the zero value useful when doing so produces a natural API.

Takeaways

Every Go variable has a defined value; there is no observable uninitialized state.
Numbers start at 0, booleans at false, strings at "", and many reference-like types at nil.
Struct fields recursively receive their own zero values.
A predictable zero state removes an entire class of uninitialized-state problems.
Good Go APIs often make their zero value useful, but not every zero value is safe for every operation.

DEV Community: Triệu Mẫn Trà

[Golang] Why Go Has Both `make` and `new`

The Concept

Why Isn't the Zero Value Enough?

Small Runnable Example

What Actually Happens?

new

make

A Common Mistake: new(map[...])

What About Slices?

Nil Maps and Nil Channels Behave Differently

Nil slice

Nil map

Nil channel

Practical Example

When Should You Use new?

When Should You Use make?

A Simple Mental Model

Takeaways

[Golang] Why Go Variables Have Zero Values Instead of Being Uninitialized

What Is a Zero Value?

Small Runnable Example

What Actually Happens?

Why Is This Useful?

Zero Values Can Make Types Immediately Useful

Designing Your Own Useful Zero Value

Common Mistake: Zero Value Does Not Mean "Ready to Use"

Practical Example: Backend Configuration

When Should You Rely on Zero Values?

Takeaways

`new`

`make`

A Common Mistake: `new(map[...])`

When Should You Use `new`?

When Should You Use `make`?