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

51–60 of 119 posts

Re: Typed nils in Go 2

#51

Post by masklinn »

laumars wrote: post #46
coldtea wrote: post #43

Earlier quoted context omitted.

Does that sound like an edge case?

Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much a…

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 would have failed in pretty much any other language anyway.

No, it would not. In Java, null is null whether it's typed as a concrete reference, as an array or as an interface.

Re: Typed nils in Go 2

#52

Post by the8472 »

p4lindromica wrote: post #28
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.

this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type. The only other option is to not have nil values.

> The only other option is to not have nil values.

Rust has a bottom type (!)[0] without it implementing all traits by default while using a different type (Result) for error propagation. Plus having nil/null as a a value of the bottom type violates some aspects of bottomness.

[0] https://github.com/rust-lang/rfcs/blob/master/text/1216-bang...

Re: Typed nils in Go 2

#53

Post by mrkgnao »

Go is a lesson in how complexity can't be eliminated, only distributed properly from the beginning so that one doesn't have to hack it in later with messy special-casing that needs you to know how the compiler represents things under the hood.

What happened to "lightweight typesystem that reduces cognitive load"?

Re: Typed nils in Go 2

#54

Post by Tarean »

TheDong wrote: post #29
tjholowaychuk wrote: post #14

Earlier quoted context omitted.

what about `error`?

Allow an Either monad via allowing sum types, solved. Once you have an either type, you can also get rid of nil entirely since a Maybe type is trivially created with an Either. Designing languages without a null value (other than for c-interop via e.g. `C.null`) is a solved problem.

How do you handle IO errors? They almost certainly have to be a open sum type.

Re: Typed nils in Go 2

#56

Post by wvh »

concede_pluto wrote: post #34
hoodoof wrote: post #20

This may be the "computing industry sentence of the year", if they had an award for "sentence of the year", which I'm sure they don't. Whoever they are. while nil is assigned to t2, when t2 is passed to factory it is “boxed” into an variable of type P; an interface. Thus, thing.P does not equal nil because while the value of P was nil, its concrete type was *T.

This is required to support one of the most peculiar features I've ever seen--method dispatch on the concrete type of object that isn't there.

This is where language design morphs into philosophy...

Re: Typed nils in Go 2

#57

Post by ghthor »

TheDong wrote: post #29
tjholowaychuk wrote: post #14

Earlier quoted context omitted.

what about `error`?

Allow an Either monad via allowing sum types, solved. Once you have an either type, you can also get rid of nil entirely since a Maybe type is trivially created with an Either. Designing languages without a null value (other than for c-interop via e.g. `C.null`) is a solved problem.

I see no reason that a good proposal and example implementation wouldn't be accepted for addition to go. The Either/Maybe monad is so powerful and is incredibly straight forward to use. So the argument from a language user perspective is already won, it's makes the intention of code much clearer and gives the type checker massive help in verifying that your intention is the only possibility at runtime.

I expect the implementation and grammar/syntax addition would be the most difficult as that seems to be what one of the main focuses was during Go's infancy, make the language as easy as possible to parse/lex.

Re: Typed nils in Go 2

#58

Post by coldtea »

laumars wrote: post #46
coldtea wrote: post #43

Earlier quoted context omitted.

Does that sound like an edge case?

Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much a…

>Checking the value of a property after you've nil'ed the parent object is enough raise an exception in most languages.

Only you're not doing that here. If anything, it's the inverse.

>But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.

In other languages the interface can be null as a value even if the interface has a not-null type.

Re: Typed nils in Go 2

#59

Post by mrkgnao »

laumars wrote: post #45
knocte wrote: post #32

Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks

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

The next decade will see Go adding in most or all the complexity real-world software asks for, without ever admitting that maybe it should've been supported from the beginning without the hacky workarounds.

> Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids[...]

Even though the bit in italics is pretty much the opposite of the "Go/JS pitch", I'll bite.

Sure, learning to code at a high level means you need to take time to learn things (which is the opposite of the pitch). I just don't get why teaching yourself to "navigate the [brokenness]" of a language that was out-of-date the day it was released is preferable to learning to write in an expressive language that won't artificially handicap you or provide you with an arsenal of footguns.

In all the time you were casting to and from interface{}, you could be exploring and using powerful and practical new ideas that make it less likely you'll suffer for failing to check one of those "err"s.

Re: Typed nils in Go 2

#60

Post by ghthor »

mrkgnao wrote: post #53

Go is a lesson in how complexity can't be eliminated, only distributed properly from the beginning so that one doesn't have to hack it in later with messy special-casing that needs you to know how the compiler represents things under the hood. What happened to "lightweight typesystem that reduces cognitive load"?

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 exist. Followed by ideas and/or examples to make it better so let's all try.

I think Maybe Types would be an amazing feature to add. Closed types would also be an outstanding win from a UX perspective. Neither of those concepts would add more cognitive load then they remove in my opinion.

Post reply on HN