Hacker News Reader

Comment by jerf | Hacker News Reader

The last bit of information you need to understand that is that unlike some other languages you may be used to, "nil" is a perfectly valid value for a pointer to have. You can write methods like this:

    func (o *Object) ReturnSomething() int {
        if o == nil {
            return 0
        }
        return o.SomeOtherValue
    }

It is also therefore legal to return in an interface value a nil pointer to a struct of a particular kind, and therefore "an interface containing a nil pointer of a particular type" and "an interface containing nothing at all" are fundamentally different things that can not be collapsed together.

So as Vendan says, it is just part of the language. All languages have this sort of wart in them, where two or more perfectly sensible decisions interact to create something that isn't sensible at first glance.

(I'm still in favor of going back in time and changing Go to have non-nillable values, but that ship has certainly sailed.)

View on HN

Java and C# also have interfaces and they don't have this strange behavior around null. I don't see how it's any sort of natural consequence of having null plus interfaces. Rather I suspect the reason is that the type equality operator was implemented to check one word and not the other when comparing two-word interface types, and the behavior that resulted was eventually specified instead of changing the implementation to compare both words.

> unlike some other languages you may be used to,

The languages I'm used to don't even have `nil`.

> "nil" is a perfectly valid value for a pointer to have.

So, just like C and Java. I don't see the difference.

> You can write methods like this: (snippet)

Oh, now I get it: `nil` itself isn't a value. `nil` is syntactic sugar that expands into a nil value. (In other words, confusingly enough, `nil` and “nil value” are different things!) This is unlike Java, where `null` itself is a value.

It would be very helpful if people described things precisely.

> All languages have this sort of wart in them, where two or more perfectly sensible decisions interact to create something that isn't sensible at first glance.

This means that at least one of the two (or more) decisions was less sensible than it originally seemed. Good design decisions don't introduce warts into a system.

nil doesn't "expand", it's just what it is. You have to bear in mind that methods are roughly syntactic sugar from

  func (o *Object) ReturnSomething() int

  func  ReturnSomething(o *Object) int

In the first case, it may "seem" that a nil Object would be invalid, but in the second case it's obviously valid, and makes complete sense. It may be described as a "wart", but it makes complete sense to me. The issue is, in my opinion, that people drag their own expectations into programming languages as they learn them.

In this case, Java and C# have the same feature and don't have this behavior around null. I think it's reasonable for people who have seen identical features in other languages to expect similar behavior when learning new ones.

They don't have the same feature of "I can call a method on a null value", at least, not that I've seen... You are calling them identical features when the fact is that they aren't. C# and Java both have generics, do they perform identical? Haskell has generics too, but I bet they'd throw a shit-fit if you tried to say "Oh, C# has generics too, so why would I bother with Haskell?"

The ability to call a method on a nil receiver doesn't have anything to do with what comparisons should do. Semantically, the question is whether == should compare the values or the vtables. In no other language I know of does it compare vtables.

If x.Foo() and y.Foo() do different things and return different values, clearly x != y, and golang needs some kind of SQL-style is-null check rather than using equality to check for null.

But dynamic dispatch on "what type of object do I not have?" is still a damn weird thing to want.

Interface comparisons check both, the value and the dynamic type. Describing that as "comparing vtables" is misleading.

It the types don't match, the operands are not considered equal. Type and value have to match for two interface values to be equal. How does that not make sense?

For mismatched dynamic types you can't meaningfully compare the values in the general case, so of course you need to consider types.

> Type and value have to match for two interface values to be equal. How does that not make sense?

Because people expect == to compare values, not types. Nobody has ever questioned this behavior in Java and C#.

Having dealt with languages that don't, I much prefer ones that do. The thing is, most languages DO basically check vtables, in that 2 values with different types will never be equal (unless there is implicit casting or some kind of equality override). For instance, 1 == "1" is valid, and true, in PHP, even though that is less then ideal. The difference, of course, is that most of those checks are done at compile time in many languages. Go will do some checks at compile time, but it's specifically unable to do some of them due to the "dynamics" of how interface variables work.

You can call a method on a null value in Java and C#. It's perfectly defined behavior: throwing a NullPointerException.

yes, and it's a completely different behavior then Go, where it's perfectly defined as well: you call that method with a nil pointer as the receiver. Please don't act like those 2 behaviors are anywhere near similar.

Reply on news.ycombinator.com