The billion dollar mistake
“It was the invention of the null reference in 1965. […] This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.”
C. A. R. Hoare, inventor of nil
nil, in Go, is used to represent the idea of “you expected something to be here, but there is nothing” for certain types (pointers, slices, interfaces, maps, channels, and functions). This is a very useful concept; not only it can be used by the logic of your programs to express lack of something (e. g. a
http.Request can have no body, in which case its
Body field is
nil), but also provides a meaningful way of initializing variables and fields of those types.
nil has a problem, though. Sometimes the code expect something to be something, but it is
nil instead. In those situations, the program usually crashes; those are the infamous
invalid memory address or nil pointer dereference panics. There is no way of preventing those situations except carefully reasoning about what do you write, and hoping that testing catches all possible misses. of This is often not the case. Even when it is, the process of achieving it is costly, if not because of crashes in production, because of developer effort spent on it.
In SGo, this nothingness concept is represented in a way that the compiler can track, so those situations never cause a crash while running the program, but simply prevent the program from even compiling.