Having fun with Go's nil, interfaces and errors • Hacker News Board

Re: Having fun with Go's nil, interfaces and errors

#31

Post by katcipis » Sat, Sep 17, 2016, 10:10 PM UTC

zeeboo wrote: post #10

catnaroek wrote: post #6

Earlier quoted context omitted.

> Except it's not a language implementation detail, it's part of what the language is. Okay, but what was the rationale for designing the language like that?

An interface being equal to nil just because the value it contains is nil would be even more confusing. For example, imagine if you had two interface values, one holding a nil * T and one holding a nil * S. They would both be equal to nil, but not equal to each other, losing transitivity of equality. Also, sometimes nil is a perfectly valid value of something and can implement interfaces. You can call methods on nil…

I had not thought about transitivity on equality, now it makes even more sense to behave like this. Thanks.

Re: Having fun with Go's nil, interfaces and errors

#32

Post by catnaroek » Sat, Sep 17, 2016, 10:19 PM UTC

Vendan wrote: post #28

pcwalton wrote: post #26

Earlier quoted context omitted.

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

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

Re: Having fun with Go's nil, interfaces and errors

#33

Post by benguild » Sat, Sep 17, 2016, 10:21 PM UTC

Even Google's App Engine SDK has its own variant of the "multi-error" ... like an array of errors in one.

Re: Having fun with Go's nil, interfaces and errors

#34

Post by Vendan » Sat, Sep 17, 2016, 10:26 PM UTC

catnaroek wrote: post #32

Vendan wrote: post #28

Earlier quoted context omitted.

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.

Re: Having fun with Go's nil, interfaces and errors

#35

Post by aikah » Sat, Sep 17, 2016, 10:34 PM UTC

catnaroek wrote: post #2

> Why ? It seems to me that it happens because how interfaces are implemented Why on Earth should a user of a high-level language have to care about language implementation details? > What the actual fuck ??? Exactly.

The worse is not, that. I think the worse is that, unlike Java, a race condition in Go has a totally undefined behavior that can corrupt the memory of the entire system your Go app is running on. You can effectively shut down your computer with a race condition in a Go program, and it actually happened to me many times on Windows, with 3rd party Go tools that didn't handle concurrency carefully. Go concurrency is truly unsafe, C style.

Re: Having fun with Go's nil, interfaces and errors

#36

Post by pcwalton » Sat, Sep 17, 2016, 10:51 PM UTC

Vendan wrote: post #28

pcwalton wrote: post #26

Earlier quoted context omitted.

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.

Re: Having fun with Go's nil, interfaces and errors

#37

Post by prodigal_erik » Sat, Sep 17, 2016, 11:03 PM UTC

pcwalton wrote: post #36

Vendan wrote: post #28

Earlier quoted context omitted.

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.

Re: Having fun with Go's nil, interfaces and errors

#38

Post by mappu » Sat, Sep 17, 2016, 11:25 PM UTC

sdegutis wrote: post #9

Vendan wrote: post #3

Earlier quoted context omitted.

Except it's not a language implementation detail, it's part of what the language is . You might as well ask why a user of another language needs to know what a class is, or how inheritance works. Too many people seem to be assuming "Oh, it's like void*, so it must act like that always!", but it's not.

After using Go for a few years, I've learned (the hard way) that Go does not separate the concepts of implementation details and the official language specification. The official implementation is the language, and they're inseparable. This is why a lot of design decisions about the language make you say "wait, what? why does it need to be that way?" and the community's official answer is "because that's how it works…

Do you have any examples of this?

Re: Having fun with Go's nil, interfaces and errors

#39

Post by mappu » Sat, Sep 17, 2016, 11:29 PM UTC

aikah wrote: post #35

catnaroek wrote: post #2

> Why ? It seems to me that it happens because how interfaces are implemented Why on Earth should a user of a high-level language have to care about language implementation details? > What the actual fuck ??? Exactly.

The worse is not, that. I think the worse is that, unlike Java, a race condition in Go has a totally undefined behavior that can corrupt the memory of the entire system your Go app is running on. You can effectively shut down your computer with a race condition in a Go program, and it actually happened to me many times on Windows, with 3rd party Go tools that didn't handle concurrency carefully. Go concurrency is tru…

This shouldn't happen on any kernel with memory protection. Userspace corruption, sure, but shutting down the computer is unrealistic unless you are running Go code on Windows 98 or classic Mac OS.

Re: Having fun with Go's nil, interfaces and errors

#40

Post by fizzbatter » Sat, Sep 17, 2016, 11:41 PM UTC

junke wrote: post #27

> This is a very interesting situation (and not a very common one for me) because it is where Go’s simple errors as values decisions shines. Doing this kind of thing with exceptions would be pretty clumsy, [...] Just because a language supports exceptions does not mean you always have to use them. You can always use a helper function to catch any error and return it as a value.

Wouldn't that basically be replicating a return value-error approach, in a more cumbersome way though?

You could argue that Go can use Exceptions in the same manner as X lang too, by using panic and recover... but most people seem to not like that.

With Go and Rust, return value error handling is just simply nice. There's no question about if a function might error out, just look at the signature.