var myString string
var myInt int
var myBool bool
var myFloat float32
var mySlice []bool
var myArray [3]bool
var myMap map[string]bool
var myPtr *bool

fmt.Println(myString) // ""
fmt.Println(myInt)    // 0
fmt.Println(myBool)   // false
fmt.Println(myFloat)  // 0
fmt.Println(mySlice)  // []
fmt.Println(myArray)  // [false false false]
fmt.Println(myMap)    // map[]
fmt.Println(myPtr)    // <nil>

type MyStruct struct {
    SomeBool bool
    SomeInt  int
}
var myStruct MyStruct
fmt.Println(myStruct) // {false 0}

type MyInterface interface {
    String() string
}
var myInterface MyInterface
fmt.Println(myInterface) // <nil>

err := json.Unmarshal([]byte(`{"SomeInt": 5}`), &myStruct)
if err != nil {
    panic(err)
}
fmt.Println(myStruct) // {false 5}

myType := reflect.TypeFor[MyStruct]()
myStruct := reflect.New(myType).(MyStruct)
fmt.Println(myStruct) // {false 0}

var mySlice []bool
fmt.Print(len(mySlice)) // 0
mySlice = append(mySlice, true)
fmt.Print(len(mySlice), " ", mySlice) // [true] 1


var myMap map[string]bool
fmt.Print(len(myMap)) // 0
myMap["foo"] = true   // /!\ panic: assignment to entry in nil map /!\

var myChan chan int
myChan <- 42 // Block forever.
foo := <-myChan // Block forever.

#include "stdio.h"

int main() {
    int value;
    int value2;
    printf("%d %d\n", value, value2); // 1 43659360
                                      // (or any other value)
}

var myValue
console.log(myValue) // `undefined`

let my_string: String;
println!("{}", my_string); // error[E0381]: used binding `my_string` isn't initialized

use std::mem;

fn main() {
    let x: i32 = unsafe { mem::uninitialized() }; // undefined behavior! ⚠️
    println!("{}", x); // 16843009
                       // (or any other value)
}

var myString *string
// or
type MyStruct struct {
    SomeString *string
}
var myStruct MyStruct

The first consequence was that the memory value represented by a sequence of 0s had to be valid for every type:

For struct, the designers had two possibilities.

First, they could have followed Java, Python, etc. and decided that all structs behaved as pointers, and consequently that a zero struct is nil. Or they could have gone with zeroing the content of structs, as… well, in fact, these same languages.

This is where the design of Go’s zero values intersects, I believe, with another design choice: the designers of Go wanted to favor performance, as long as it didn’t make the compiler more complex. Avoiding complexity meant that they did not want a JIT, nor a compiler that could alter the layout of data structures. Which meant that they needed to make memory layout explicit in the language, to let the developers optimize themselves. Which meant that they had to materialize the difference between a struct allocated within its container (e.g. on the stack, or within the space of a container struct) and a struct allocated somewhere (else) on the heap.

Which meant that they needed to make pointers explicit. Which meant that they could not zero structs to nil.

So the design of Go went with zeroing the content of structs instead of treating all structs as references and zeroing the reference itself.

3. The zero value for struct is the struct filled with zeroes, rather than nil.

Now… what’s a zero interface?

If you have ever programmed in Go, you know that a zero interface can be… surprising.

func IsNil(v any) bool {
	return v == nil
}

var a any
var b *int
fmt.Println(IsNil(a), IsNil(b)) // true false

It’s not that v == nil always fails when v is an interface, it’s that it doesn’t always work. Needless to say, that’s not my favorite part of Go. Part of this is a consequence of the zero value principle.

When we declare var a any, a is zero-ed. It literally contains a nil pointer. Similarly, when we declare var b *int, it contains a nil pointer. Now, when we cast a or b or any value to any, we need to store several pieces of information:

(actually, 2. and 3. are pretty much equivalent, so you only need one of these pointers).

But since a and b both MUST contain exactly a nil pointer, this means that the data cannot be stored on the stack when the stack is initialized. They MUST be added by the compiler when a value is actually used as an any and the call is not inline.

4. Type information must be added dynamically.

By opposition to struct, slices and strings are always pointers. So the designers of Go could have decided to make any operation on a zero slice or a zero string invalid. However, if you have programmed in Go, you know that this isn’t the case. The zero value of a slice is an empty slice and the zero value of a string is an empty string.

Why? I believe that there are two reasons.

First, whether you’re creating an API, a data structure or a programming language, in most cases, you’ll try to reduce as much as reasonably possible the space of possible failures. Making the program panic with any operation on an invalid slice or string is adding failure states, so removing the possibility of reaching these failure states makes the language… well, less fallible.

Note that, these are Go failure modes. For many applications, having an incorrect slice or string (for instance, the empty slice or string) is also a form of failure. In most applications I write, it’s a worse kind of failure than a panic, because it’s harder to detect and fix, but if you are writing log processors ³, having a processor that sometimes prints an empty string when the input data is incorrect is most likely less of a problem than having a processor that panics whenever it encounters data it doesn’t understand.

Second, the empty slice or the empty string are absolutely valid value. They’re even quite common values, especially for a slice that has just been created. By adopting the convention that the zero slice is the same thing⁴ as the empty slice, the designers of Go have cut to zero the initialization time of an empty slice – all it takes is zeroing the memory, which is exactly what Go is doing in the first place.

edit In the first version of this blog post, I (wrongly) deduced that this was the reason for which strings were read-only and slices required append. But actually, that’s very likely not the case.

As slices and strings, maps are pointers. So Go’s designers could have decided that:

And they decided…

var myMap map[string]bool
_, found := myMap["foo"]
fmt.Println(found) // false

myMap["foo"] = false // panic: assignment to entry in nil map

…a bit of both?

Let’s start with the panic at myMap["foo"] = false. For the purpose of this conversation, let’s remove the syntactic sugar and pretend that this is actually maps.Set(myMap, "foo", false).

Could we rewrite this to let the map grow?

func Set[K comparable, V any](container Map[K]V, key K, value V) {
    if container == nil {
        container = Make()
    }
    internals.Set(container, key, value)
}

This doesn’t work because we’ve mutated container locally, but never returned it. We could get around this, by making it:

func Set[K comparable, V any](container* Map[K]V, key K, value V) {
    if container == nil {
        *container = Make()
    }
    internals.Set(container, key, value)
}

But now, Set is an operation that takes a pointer to a pointer (recall that Map is itself a pointer), instead of a single indirection. There is a fairly large performance penalty for that, which the designers of Go presumably didn’t want to pay. So they decided to panic instead. I believe that this is the right behavior, although the irregularity does chafe.

Now why doesn’t _, found := myMap["foo"] panic? One can only assume that this another attempt to limit the number of failure states in the language.

As slices, strings and maps, chans are pointers. So Go’s designers could have decided that:

And they decided…

var myChan chan int
go func() {
    myChan <- 42 // Block forever.
}()
go func() {
    foo := <-myChan // Block forever.
}

…none of the above?

Alright, this one baffles me. It’s clear that making zero channels valid is meaningless (so no 1. and no 3.), but I have no idea why the designers of Go decided that blocking forever is better than a panic, especially since writing to closed channels already cause panics. Maybe this comes from a specific school of thought? Maybe it simplifies some tests? After all, Obj-C had the same policy with NULL objects dropping messages instead of segfaulting.

If somebody manages to puzzle this out, I’m interested.

edit Ahah, a response was provided by /u/TheMerovius in a Reddit comment! If you select in a loop, this will let you easily disable some cases by zeroing some of the channels!

There’s a motto within the Go community that you should make zero values work for you, rather than fighting them.

So let’s take a look at a few cases in which you can benefit from zero values.

Some data structures manage to be valid when they are zero. The empty slice and the empty string are examples, but the most quoted example is presumably sync.Mutex.

I haven’t found any guidelines on how to replicate this feat, but I’m sure that there are a few patterns for that. One I’ve seen essentially amounts to delaying construction:

func MyStruct struct {
    isInitialized bool
    Field MyField
}

func (me *MyStruct) DoSomething() {
    if !me.isInitialized {
        // Perform initialization.
    }
    // Now do stuff.
}

To a large extent, this is what unmarshaling does:

func (me *MyStruct) UnmarshalJSON(source []byte) error {
    // Fill `me` with the contents of source.
    if me == nil {
        me = &MyStruct {}
        me.Field = ...
    }
}

For better or for worse, Go doesn’t have sum values (this might be the topic of another blog entry). Since it also doesn’t have (or at least doesn’t recommend) stack unwinding, this means that every function that might return a result or an error must return both.

That’s probably the most noticeable pattern when looking at go code:

func doSomething() Value, error {
    // ...
}
value, err := doSomething()
if err != nil {
    return Stuff{}, fmt.Errorf("let's add some context: %w", err)
}

Some people (including yours truly) don’t particularly enjoy the idea of having to deal with a meaningless value that will presumably cause a failure state if we ever mistake it for a valid value. But if we have to deal with such meaningless values, zero values feel tailored for this kind of use. In this snippet, if we didn’t have the ability to return a zero-ed Stuff{}, the only alternatives would be to:

As I mentioned quite a few times by now, I don’t particularly like zero values. They regularly creep into my data structures and produce weird results much later, which increases the time I spend debugging. I don’t debug for fun.

But if one looks harder, the problem isn’t with the zero values themselves. It’s with the fact that Go doesn’t support constructors (as in “being able to define functions that you must call to construct a value of the given type”) – constructors would remove ~100% of the problems that materialize as zero values in my data structures. Why doesn’t Go support constructors? Presumably because the language works without constructors and the designers Go simply didn’t want to complicate the specifications. Also, Go relies a lot on reflection, and it feels like adding constructors would break reflection as it exists – either that, or reflection would break the constructors.

Well, writing this blog entry gave me the opportunity to dive a little bit deeper into zero values, the problems I have with them and confirm that no, the designers of the Go language are not crazy or lazy, they just have priorities different than mine. Go is a language of the worse-is-better design philosophy, much as Unix, and this is a design philosophy that has delivered in many occasions.

I don’t think I’ll ever fall in love with Go (at least not while it’s Go 1.x), but it’s definitely a language that has its uses.