Having fun with Go's nil, interfaces and errors
katcipis.github.io
Having fun with Go's nil, interfaces and errors
1–10 of 52 posts
Re: Having fun with Go's nil, interfaces and errors
#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.
Re: Having fun with Go's nil, interfaces and errors
#3> 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.
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.
Re: Having fun with Go's nil, interfaces and errors
#4I got bit by this the other day when returning a nil pointer to a struct as an error. It was incredibly frustrating when I finally figured out what was going on, and I'm curious if there's a good reason to distinguish between these 2 types of nil or if it was just an oversight/mistake during the language design process.
Re: Having fun with Go's nil, interfaces and errors
#5I got bit by this the other day when returning a nil pointer to a struct as an error. It was incredibly frustrating when I finally figured out what was going on, and I'm curious if there's a good reason to distinguish between these 2 types of nil or if it was just an oversight/mistake during the language design process.
Most likely the reason is keeping the language implementation simple. Java-style `null` is actually quite subtle: http://stackoverflow.com/a/2707333/46571
Re: Having fun with Go's nil, interfaces and errors
#6> 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.
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.
> 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?
Re: Having fun with Go's nil, interfaces and errors
#7I had run into the same situation of handling multiple errors. Assuming I wasn't the first to need such a thing I found multierror[1]. Searching now returns more choices some of which use a nil []error and some with structs.
[1] github.com/joeshaw/multierror
Re: Having fun with Go's nil, interfaces and errors
#8Earlier 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.
> 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?
Sometimes you try and make one feature work a certain way and that decision has unintended consequences. Most languages have surprises like this.
In this case, it's an implicit conversion from "nil" to the "nil value" of a given type. This is convenient in many cases, but causes confusion in other cases.
Re: Having fun with Go's nil, interfaces and errors
#9> 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.
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 best with how it's implemented".
Re: Having fun with Go's nil, interfaces and errors
#10Earlier 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.
> 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 receivers because method calls are just curried function applications over the value. It would be odd if the interface compared equal to nil just because I happened to implement it with a value that's valid with nil.