Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typed nils in Go 2

dave.cheney.net

Post reply on HN
Print view View original

71–80 of 119 posts

Re: Typed nils in Go 2

#71

Post by Sharlin »

tjholowaychuk wrote: post #14
maerF0x0 wrote: post #13

IMO the language made a mistake by allowing nil to satisfy any interface . When I write a function like func DoStuf(i ILoveGoer) { i.LoveGo() // Panic on nil } its hard to reason about because it doesnt look like you have a pointer, looks like you definitely have a value. IMO a nil should not be allowed for an interface. So the only way to create an interface var is in conjunction with assignment.

what about `error`?

Emulating the sum type val|err with a product type (val, err) - where val and err are implicitly nilable - is one of Go's biggest design smells in the first place.

Re: Typed nils in Go 2

#72

Post by junke »

BlaXpirit wrote: post #67
heythere124 wrote: post #65

Earlier quoted context omitted.

Python does that too.

I thought it did not need to be mentioned, but dynamically typed languages don't count for this comparison. Every value is like a union of every type, and compile time type checks are impossible.

Why would a language define an empty type if not for static type checking?

Re: Typed nils in Go 2

#73

Post by laumars »

mrkgnao wrote: post #59
laumars wrote: post #45

Earlier quoted context omitted.

I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if y…

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…

> Does this look like a design mistake or a bit of oversight?

Honestly, I don't mind error handling in Go. I've used a wide variety of languages in production systems (I've lost count but it's more than a dozen) and I've found Go to be surprisingly good at giving detailed, context aware breakdowns of where issues arise and allowing me to easily handle them. Sure there are a thousand different ways to do this and Go picked the ugliest, but in spite of that I've found it to be surprisingly effective - even in the more complex projects I've written like murex (my alternative UNIX $SHELL) and the odd Linux FUSE file system I've written to scratch a particular itch.

In fact for as many complaints like yours I've read there are also as many seasoned developers complementing Go's error handling. So I really think that particular issue is more a matter of personal taste rather than poor language design.

However I'm _not_ going to defend the nil thing nor how interface{}'s are (ab)used as an alternative to generics. Those _are_ just bad design choices.

But for all of Go's sins, I still find myself more productive writing Go code than I have in any other language for a long time (probably since writing Pascal in Borland's Turbo Pascal back in the 90s). Hence why I defend Go. I can understand idealistic opinions about language design (Go is opinionated too after all) but frankly what really matters is a developers ability to get an idea into something executable. And I feel a lot of the complaints about Go really miss the point about how productive that language is to a great many people and without sacrificing too much control to be useful in a practical sense.

Re: Typed nils in Go 2

#75

Post by coldtea »

laumars wrote: post #63
masklinn wrote: post #51

Earlier quoted context omitted.

You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. This issue can occur for any function which takes an interface-typed parameter. That's usually how it happens: somebody passes in a `nil` which comes from a pointer-typed variable: https://play.golang.org/p/ADTvLDDrw6 > But regardless of the bad design of Go around the usage of "nil", the code…

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the…

>Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

Most OO languages wont report an interface as non null if its value is null. Go will.

Re: Typed nils in Go 2

#76

Post by laumars »

coldtea wrote: post #75
laumars wrote: post #63

Earlier quoted context omitted.

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the…

> Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. Most OO languages wont report an interface as non null if its value is null. Go will.

Indeed - I wasn't defending Go's behavior here. I was just replying to your question about whether it is an edge case or not. Since the code would be broken in any OOP language I do consider this to be an edge case. But that doesn't mean I like nor would defend Go's nil type system.

Re: Typed nils in Go 2

#77

Post by sagichmal »

mrkgnao wrote: post #59
laumars wrote: post #45

Earlier quoted context omitted.

I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if y…

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…

The error handling idiom in Go is one of its strongest properties. Forcing developers to accommodate the error path inline and at each callsite makes code resilient and robust. It would stand to benefit from a Maybe feature, but even as-is it's a huge net positive versus e.g. exceptions.

People who complain about it don't grok the Go ethos. That's fine, it's not for everyone.

Re: Typed nils in Go 2

#78

Post by dullgiulio »

gondo wrote: post #68
masklinn wrote: post #50

Earlier quoted context omitted.

Yes. The interface holds the concrete type of the value, if there is no concrete type it will be nil, so if you assign a nil to an interface-typed variable directly, you'll have a (nil, nil). If you first assign the nil to a pointer type T then assign/convert that to an interface type, you'll get (* T, nil). Here's a trivial demo: var a interface{} = nil // (nil, nil) var b *int = nil var c interface{} = b // (*int,…

thanks for the example. so the answer to @dullgiulio question could be done by using reflection: var a interface{} = nil // (nil, nil) fmt.Println(reflect.TypeOf(a) == nil)

Thank you for your answer. I was writing from the phone and didn't make myself clear. My question is: what are the legitimate use cases for interfaces that are half-nil?

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

#79

Post by pjmlp »

mrkgnao wrote: post #64
ghthor wrote: post #60

Earlier quoted context omitted.

It's really easy to criticize where mistakes were made. The intention was to make a simple language and it worked. The idea resonates with many many engineers even ones such as I that love writing powerful pure fn code. The intention was great and the result wasn't that great, but it still works pretty dann well. Go is an open language and they are asking for well thought out proposals on where & why the problems exi…

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

Re: Typed nils in Go 2

#80

Post by dullgiulio »

mrkgnao wrote: post #59
laumars wrote: post #45

Earlier quoted context omitted.

I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if y…

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?

Post reply on HN