Hacker News Reader

Comment by Groxx | Hacker News Reader

Nils are among the biggest wats in Go in my experience. "useful nils" just compounds "the billion dollar mistake" into something even more nefarious and even harder to identify during code review.

Along similar lines: WAT 15. Under what circumstances do you expect a nil var return to become non-nil? Did you even know that was possible?

View on HN

> Along similar lines: WAT 15. Under what circumstances do you expect a nil var return to become non-nil? Did you even know that was possible?

Yeah. Typed nils are a horrible, horrible feature: when you cast a value to an interface, it creates a fat pointer of (Type, Value). From a nil, that's (nil, nil) but from a nil Foo that's (Foo, nil). And since `==` just does a straight value comparison, (nil, nil) != (Foo, nil).

This actually has an official FAQ entry telling you to go fuck yourself: https://golang.org/doc/faq#nil_error

I really enjoyed Go until I started trying to work with interfaces. The fact that you have to understand the implementation details at this level in order to use them reliably, IMO, shows that when the Go team talks about language simplicity, what they really mean is _compiler_ simplicity. At some point, the complexity starts getting offloaded onto the end developer.

That said, the fact that the crowd only offered an incorrect guess four times out of 16 is telling. This really didn't have the same feel to me as the original WAT talk, which is really full of truly strange things.

IMO, Go is an attempt to design a modern language using C philosophy, and it shows. Like, this whole thing about slices is because they insist on trying to make arrays + slices into a data structure that does everything "good enough", while mostly retaining their performance profile. And so you end up with all of those abstractions that look kinda sorta like what you'd expect in a more typical modern language - but the moment you start poking hard at them, they leak like a sieve.

It doesn't have anything to do with implementation details, even though the weird set of rules from the article implies that.

Dump those rules for a much simpler insight:

When comparing interfaces, type and value must match to compare equal.

So, (nil, nil) compares NE to (*myFancyErrorType, nil) for the same reason that (float64, 0) and (uint16, 0) do.

It isn't all that complicated. I don't see a real and non-insane alternative to it. Do you?

Sure there is. Do what the vast majority of other languages do - don't bundle behavior and nil like this. Or even better, make nullability a proper first-class citizen so this nonsense can be prevented at compile time.

Reply on news.ycombinator.com