Fixing the Billion Dollar Mistake in Go by Borrowing From Rust

panic: runtime error: invalid memory address or nil pointer dereference
If you ever used Go, you probably saw this error at least once. Somewhere a nil pointer or nil interface was passed to a function that doesn’t handle nil. In all cases, this is a programming error, either the function should handle nil or the caller shouldn’t have passed nil to the function. This Go experience report will try to make the case that nil is often not needed and being forced to have nil-able pointers and interfaces can cause panics in production. We’ll also briefly discuss how Rust solves this issue and how their solution could be applied to Go.
Nil Can Be Useful
Let’s first start off by showing why allowing a value to be nil can be useful. The main use case for nil is indicating that a value is “missing." A good example of this is some code that parses JSON and needs to know if a field was provided or not. By using a pointer to an int you can differentiate between a missing key and a value that was 0: