Surprised by the Go programming language's treatment of nil

Oct 31, 2013 · 3 minute read · Comments
GonilC

So I happened to see an announcement of Go version 1.2. I saw something that disturbed me, having to do with nil, a “favorite” topic of mine.

What I know about Go

I don’t currently use the Go programming language, although there actually is a local Pittsburgh Go programming meetup group, the Go Steel Programmers, whose meetings I have never attended.

Some months ago I did, out of curiosity (and respect for any new language that I hear about people actually using to get stuff done), work through the tour of Go tutorial, to learn about the Go language. I installed packages on my machine, and wrote some compiling and running programs. I know just enough that I could code in Go for some project if I wanted to.

nil

What caught my eye in the Go 1.2 announcement was a note about changes in the semantics regarding nil.

For the record, I don’t believe any new programming languages should be invented that have the nil construct, Hoare’s “billion dollar” mistake. I’ve already previously given a talk about why, so I won’t repeat the arguments here.

But I think Russ Cox’s note about nil checks speaks for itself.

It said that Go 1.2 tightens things up so that various uses (directly or indirectly) of nil will cause a runtime panic rather than silently producing an unusable pointer.

Read that again: until Go 1.2, you could get silent bad behavior, an unusable pointer. This from a language that purports to be “statically typed”, improve on C, and provide memory safety guarantees.

Before Go 1.2, a chain of code involving a nil could result in behavior of which Russ Cox wrote:

The current behavior is at best merely historical accident; it was definitely not thought through or discussed.

There is also a note about a particular special case:

(it seemed like a good idea at a time)

You can read the whole document about nil yourself. You will find that it is still not a formal spec, but more a rationale of various special cases and possible implementation details.

C culture

Go arose from C culture. It was invented by those in C culture who wanted an improvement over the known problems of C. Unfortunately, I perceive it as today’s C, in the same way that the C invented in the 1970s was born with the problems that one could have avoided already at that very time.

Conclusion

The Go language continues to evolve, which is good, but I was surprised that the full ramifications of something as dangerous as rampant nil were not thought about up front.