Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

It's not that nil exists... it that it exists everywhere (on the types that support it), with no way of restricting it. It's actually the one criticism I find the most frustrating because, unlike generics and unlike interface{} (which is sort of a repeat of the generic complaint, that's an effect), it's so easy to fix that during the initial design, and it would not have profoundly affected the rest of the language. In fact it could still be bolted on after the fact, it's that easy and low-impact. That not all types support nil in Go is itself an interesting point; zero types are better than nil, so why didn't we propagate the idea that is already in Go through the language consistently, and not let anything be nil unless we explicitly request it in the type?

With most of the rest of the criticisms it's not necessarily clear how to fix Go (that is, it may be fixable but there's no one obvious solution that just works), but that's not the case for non-nullable types. They were always possible, have been for decades, and there's just no reason not to have them and use them as much as possible in the standard lib.

Also, I'm not a hater... unless your definition of "hater" is "doesn't like every last detail about Go", in which case, sure, under that degenerate definition I'm a "hater". You really shouldn't sling that term around in a preemptive attempt to marginalize your opponent like that, for a topic like programming languages. Save it for politics.

("Programming languages ARE politics." Well, they shouldn't be. Don't fall into that trap.)

Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wrong", but the languages in use (e.g. Java) force them into situations where, for example, returning null to mean "this entity wasn't found" is substantially more productive than catching and processing EntityNotFoundException.

I think the Go designers wanted the language to be approachable for people who habitually use null to indicate meaningful state. Multiple return values offer a way out, while still allowing newbies the option to abuse nil. (although, sum types would be nicer)

I think on balance, getting people from the 1970s to the 1980s who otherwise would not have gone there is a positive thing. Even if it's not the ideal thing.

It's not out of the question that Go will make your suggested fixes once it acquires enough mindshare.

Removing nil from Go is not possible without breaking backwards compatibility. The Go core team considers nil a feature anyhow.

Go look at C#, or any other language that has this concept. The point is not that there would be no nil, anywhere, ever, the point is that you would have to ask for it, and by default, you get a type that can't contain nil.

C# even proves it can be profitably bolted on after the fact (contra pcwalton)... because that's how unobtrusive this change is. It's not like this is a complicated idea, unlike the other suggestions.

> zero types are better than nil

huh? Yeah, well. Newsflash: "nil" is nothing more than the zero-value for pointer types (and related other reference-semantics types).

Your point again? Should we rename nil with a new keyword "zero"? Fine by me.

I'd rather have a pointer initialized to a new zero-type value, or require you to initialize it as a pointer to an existing thing.

Forced-nil pointers are a disaster.

Also, please re-read my last two paragraphs.

So you'd rather have the Go runtime allocate the full structs (with all fields zeroed but still consuming the same memory) exactly everywhere they aren't even needed?

I don't know --- sounds like we would replace our current easy-to-grok, quick-to-fix "nil-pointer error" panics with obscure hard-to-debug non-panic-ing bugs because our code failed to check our now-in-every-struct custom "isInitialized bool" field?

Wouldn't you agree that the "special value nil", for pointers to complex struct types, is just as useful and essential as zero is for simple literal (non-struct) types, to represent that somewhat tricky but absolutely necessary concept of "non-existence"?

"current easy-to-grok, quick-to-fix 'nil-pointer error'"

But they aren't. That's why they're the "billion dollar mistake": http://en.wikipedia.org/wiki/Tony_Hoare#Quotations If you think they're just easy quick problems, I find it doubtful you've ever worked in a significantly sized system.

Are you aware of the fact that there are plenty of languages that actually already have non-nullable values? Have you spent any time using them? Do you understand that such languages still support null values, but you have to call for them explicitly? Do you understand that we're calling for non-nullable values not out of some sort of abstract concept of correctness floating in space, but from concrete experience? I suspect you'll find that more experience correlates with a stronger belief in the need for non-nullable fields. It seems to me the people most vigorously defending the need for nulls have obviously never tried the alternative, as evidenced by their frequent belief that it's an all-or-nothing proposition, which is not true of any language, thus strongly implying a complete lack of experience. Also implied by you asking me whether nil should even exist, which is the wrong question, again implying you don't understand the alternative I'm advocating for here.

And again... it's soooo easy to add them, even to existing languages, and soooo easy to use them. It's not an overhaul, and it's an easy way to avoid the billion-dollar mistake. The cost/benefits are just so, so clearly in favor of defaulting to non-nullable values.

Reply on news.ycombinator.com