Hacker News Reader

Comment by pcwalton | Hacker News Reader

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.

View on HN

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?"

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.

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.

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.

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#.

Reply on news.ycombinator.com