Module 1 · Lesson 1 · ~25 min read

Zero Values, nil, and Go's Philosophy

Every Go variable has a useful default without you writing a constructor. nil is not one concept — it's the zero value for several type families, and they behave differently. Get these two ideas right and half of Go's "weirdness" disappears.

The first rule: no uninitialized state

In Python, this is a NameError:

print(x)  # NameError: name 'x' is not defined

In JavaScript, it's either undefined or a ReferenceError, depending on whether the identifier was declared. Either way the concept of "uninitialized" exists at runtime.

In Go, uninitialized does not exist as a runtime state. Every declaration is immediately set to its type's zero value. The compiler won't let you have an unbound variable.

var n int      // n == 0
var s string   // s == "" (empty string, not nil)
var b bool     // b == false
var p *User   // p == nil
var xs []int   // xs == nil, but len(xs) == 0 and you can range over it
var m map[string]int  // m == nil, reading is fine, WRITING panics

This is a language-level design choice, not a style choice. It means a lot of defensive initialization code you'd write in Python or JS is unnecessary in Go.

The zero value table — memorize this

var xs []int           // nil slice
xs = append(xs, 1)       // fine: len(xs) == 1

var m map[string]int   // nil map
m["x"] = 1              // PANIC: assignment to entry in nil map

var _ = m["x"]           // fine — reads return zero value (0 here)

What nil actually is

Python has None, a singleton instance of NoneType. JavaScript has null and undefined. Hack has null. In all these languages, the null-like value is (roughly) uniform — one kind of "nothing."

In Go, nil is the zero value of six distinct type families: pointers, interfaces, slices, maps, channels, and functions. Each family's nil is a different runtime representation:

• A nil pointer is literally the zero address.
• A nil slice is a slice header with ptr=nil, len=0, cap=0.
• A nil map is a nil pointer to the internal map struct.
• A nil interface is a two-word value (type descriptor + value pointer) where both words are zero.

You can't compare a nil of one type family to nil of another without conversion. You can only assign nil to a variable of a nilable type.

var x int = nil  // COMPILE ERROR: cannot use nil as int value

The nil-interface trap

This one will bite you. Read it twice:

type MyErr struct{}
func (*MyErr) Error() string { return "oops" }

func doThing() error {
    var err *MyErr  // err is (*MyErr)(nil)
    return err        // returned as an error interface
}

func main() {
    err := doThing()
    if err != nil {     // TRUE! and now we're hurting
        fmt.Println(err.Error())  // panic — *MyErr is nil so Error dereferences nil
    }
}

The interface value is not nil, because its type descriptor is set to *MyErr. Only its data pointer is nil. An interface equals nil only when both type descriptor and data pointer are zero.

This trap is the single most common nil-related bug in production Go code. The Canton codebase, any gRPC Go client, any HTTP handler — all rely on this pattern being handled correctly.

Quick check

var m map[string]int
fmt.Println(m["missing"], len(m))

type Config struct {
    Timeout time.Duration
    Retries int
    Hosts   []string
    Labels  map[string]string
}

var c Config
c.Hosts = append(c.Hosts, "a")
c.Labels["env"] = "prod"

The philosophy behind all this

Go's designers made three interlocking choices:

1. Every type has a useful zero value. So you can declare a variable and use it immediately. No constructors required for the common case.
2. Errors are values, not exceptions. So the type system forces you to handle or propagate them. No "what might throw here?" guessing.
3. The language has one obvious way for most things. There's no ternary, no operator overloading, no implicit conversion. Boring is a feature.

These are not neutral choices. They're trade-offs against expressiveness. Go is explicit and occasionally verbose because the designers want code to be readable by someone who didn't write it — and who may be reviewing it under time pressure.

Idioms that flow from "zero value works"

Zero-value structs are constructors

type Buffer struct {
    data []byte
}

func (b *Buffer) Write(p []byte) (int, error) {
    b.data = append(b.data, p...)
    return len(p), nil
}

// No constructor needed:
var buf Buffer
buf.Write([]byte("hi"))  // works — b.data starts nil, append handles it

This is why bytes.Buffer, sync.Mutex, sync.WaitGroup, and many other standard library types don't have constructors — the zero value is the valid empty state.

"If you do need real init, hide it in a constructor"

type Cache struct {
    m map[string]string
    mu sync.Mutex
}

func NewCache() *Cache {
    return &Cache{m: make(map[string]string)}
}

Convention: name the constructor NewX. Canton-era codebases follow this religiously.

Takeaways

• Every Go value is zero-valued by default. Embrace this — it kills a class of Python/JS bugs.
• nil is not one thing. Different type families have different nil semantics. Slices and maps behave differently under nil — maps panic on write.
• Returning a typed nil as an interface gives you a non-nil interface. Always return the literal nil from a function returning an interface type.
• Prefer the zero value. Only write a constructor when you genuinely need to initialize maps, channels, or other nil-write-panicking fields.