I enjoyed the blog article and I would like to gently reiterate the notion that a _typed nil_ in Go 2 would change the semantic of _nil_, as seen in the example expression at the end of the article: var b *bytes.Buffer var r io.Reader = b fmt.Println(r == nil) We might need to use other expressions to capture the _nil_ type of above assignment but we should enable the _value only_ equality check with `r == nil`
Can someone point me to some examples where checking that the type of an interface is nil? I have thought a bit about it but I couldn't come up with good situations.
Typed nils in Go 2
81–90 of 119 posts
Re: Typed nils in Go 2
#82Earlier quoted context omitted.
Does this look like a design mistake or a bit of oversight? There is no excuse why one should have to do result, err := Foo() if err != nil { ... } over and over again in a language designed after 2000. The usual argument is that Go's simplistic design "reduces complexity", yet explaining something basic as why the error handling system doesn't behave the way one expects needs you to know how the compiler represents…
You are doing it wrong. You should check if there is an error (not the other way around) and return early. How about you study the language a bit more in depth (including estabilished idioms) before pontificating about it?
> estabilished idioms
I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.)
Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought to improve upon and the baggage of "design patterns", GoF-alikes, etc. that they brought with them.
> return early
I was just going off what I found at https://blog.golang.org/error-handling-and-go.
I assume you meant this (in Go-ish pseudocode)?
result, err := Foo1()
if not err {
Panic(err)
}
result2, err2: = Foo2(result1)
if not err2 {
Panic(err2)
}
result1 Re: Typed nils in Go 2
#83Earlier quoted context omitted.
> Go is an open language From what I've seen, this holds only as long as you keep the proposals minimal and restricted to aforesaid hacking around the limitations built into the language. I'm happy to be shown evidence to the contrary: have there ever been any proposals, reacted to in a not-completely-negative way, that were like "uh, maybe we didn't have the right idea about , let's do this instead"? I'll argue ther…
Go has done nothing new for fast compile times, like any old timer coder will remember from Algol linage of compilers, with Turbo Pascal for MS-DOS being a good example of how long ago those fast compile times are known.
Not to mention that there are modern languages with fast compilers too. D is an example.
Re: Typed nils in Go 2
#84Earlier quoted context omitted.
> Go is an open language From what I've seen, this holds only as long as you keep the proposals minimal and restricted to aforesaid hacking around the limitations built into the language. I'm happy to be shown evidence to the contrary: have there ever been any proposals, reacted to in a not-completely-negative way, that were like "uh, maybe we didn't have the right idea about , let's do this instead"? I'll argue ther…
Go has done nothing new for fast compile times, like any old timer coder will remember from Algol linage of compilers, with Turbo Pascal for MS-DOS being a good example of how long ago those fast compile times are known.
I'm sadly too young and ignorant of CS/technology history to be well-acquainted with the "old times". (It's something I intend to fix.)
Even so, I'm all for praising the good things that Go does: if nothing, because of the tremendous mindshare it's getting and the number of people it reaches.
Re: Typed nils in Go 2
#85Earlier quoted context omitted.
Can someone point me to some examples where checking that the type of an interface is nil? I have thought a bit about it but I couldn't come up with good situations.
https://play.golang.org/p/rfq52ZmLPS
My question misses the important words "a situation where it makes sense."
As I wrote below:
Ignoring the compatibility guarantee for the sake of discussion, I feel that nobody would notice if the compiler tomorrow started short-circuiting the equality check of interfaces against nil to return true if either tuple value is nil. But maybe I'm missing some use-case.
Re: Typed nils in Go 2
#86Earlier quoted context omitted.
You are doing it wrong. You should check if there is an error (not the other way around) and return early. How about you study the language a bit more in depth (including estabilished idioms) before pontificating about it?
> estabilished idioms I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.) Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought…
1. Your assumption is wrong, I definitely didn't mean panic.
2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To use them the same way proper error handling is done in Go, you would just have more nesting and multiple unwraps, which is marginally different than Go syntax (but definitely with more compiler checking.) The arrow syntax in Go is used by channels.
Re: Typed nils in Go 2
#87Earlier quoted context omitted.
I'm all for the idea that relational fields should be NOT NULL What if the data is actually missing? How else do you record that information?
You use the default empty value, and have an extra field for missingness. Than you have real type safety.
That's a "cure" worse than the disease.
Re: Typed nils in Go 2
#88Earlier quoted context omitted.
Can't that be determined by looking at the row count? A row count of zero means it doesn't exist. A row count of 1 with a null in the selected column means the row exists the column is null. I avoid the word "empty" when referring to anything SQL related, as it is ambiguous in three value logic.
I think they're referring to outer-joined tables. SELECT a.id, b.name FROM a LEFT JOIN b ON a.id = b.id If you get a NULL in the name field, you don't know if that's because there's no record in b for that id, or if there is a record in b for that id but it has a NULL name value. Sometimes that difference will be important.
While admittedly this could be seen as a mistake in SQL, you can differentiate by looking at whether b.id is NULL or not.
Re: Typed nils in Go 2
#89Earlier quoted context omitted.
You are doing it wrong. You should check if there is an error (not the other way around) and return early. How about you study the language a bit more in depth (including estabilished idioms) before pontificating about it?
> estabilished idioms I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.) Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought…
I used to fight Go's error system by creating wrapper functions to mitigate the need for nested blocks - essentially trying to "Haskellify" the code a little (for want a _very_ crude description). With time I realised I was spending more time over thinking a solutions and pontificating instead of just writing code and handling errors. Since then I've given up fighting against the language idioms I personally disagreed with and as a result I've come to appreciate some of the benefits they came with but I previously had overlooked. Ok `err != nil` is about as ugly as it comes, but it's still effective in getting the job done.
At the end of the day it doesn't make any more sense to apply Haskell methodologies to Go than it does to complain that Haskell is missing some fundamental features of Go. They're distinctly different languages. But despite this I've noticed you spend a lot of time in various Go discussions on HN moaning that Go isn't more like Haskell.
Re: Typed nils in Go 2
#90Earlier quoted context omitted.
> estabilished idioms I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.) Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought…
1. Your assumption is wrong, I definitely didn't mean panic. 2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To use them the same way proper error handling is done in Go, you would just have more nesting and multiple unwraps, which is marginally different than Go syntax (but definitely with more compiler checking.) The arrow syntax in Go is used by channels.
Apologies. In any case, monadic errors in Haskell allow you to make "failing early" automatic. Even a simple use of optional types can make a difference. For instance, here you're failing with the same error every time, like here:
a, err := squareRoot(x)
if err { handle(err) }
b, err := log(a)
if err { handle(err) }
c, err := log(b)
if err { handle(err) }
a :: Double -> Maybe Double
a