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

61–70 of 119 posts

Re: Typed nils in Go 2

#61

Post by mrkgnao »

ghthor wrote: post #57
TheDong wrote: post #29

Earlier quoted context omitted.

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 i…

> I see no reason that a good proposal and example implementation wouldn't be accepted for addition to go.

I'm sorry to bring the age-old "but generics" thing up, but how do you even implement (what Haskell-alikes call) Functor without parametric polymorphism?

The only ways I see are

a) Elm-style List.map/Array.map/Maybe.map

b) Rust-style Functor/Monad operations on specific types like Result

Which of these do you think Go would be more receptive to?

Re: Typed nils in Go 2

#62

Post by Ar-Curunir »

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…

Stuff like null or nil is a problem that's been identified for decades, and there are relatively widely-used type system approaches that solve it very nicely (sum types). It's not okay in a modern programming language to repeat the mistakes of decades-old ones in the name of "simplicity".

Re: Typed nils in Go 2

#63

Post by laumars »

masklinn wrote: post #51
laumars wrote: post #46

Earlier quoted context omitted.

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…

> 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 language. So Let's break the code down: first they create a struct exposed via an interface{}

    type T struct{}

    func (t T) F() {}

    type P interface {
        F()
    }
func newT() *T { return new(T) }

Then they create an initialized variable that object type:

    t := newT()
    t2 := t
...and set that interface{} to nil:

    if !ENABLE_FEATURE {
            t2 = nil
    }
Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed:

    thing := factory(t2)
    fmt.Println(thing.P == nil) // returns nil
If there's a likelihood that they could be working with nil interfaces then they should be first checking the value of the interface before checking the value of the methods within it. 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. So I'm not defending Go's behavior but their example is peculiar to say the least.

That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.

Re: Typed nils in Go 2

#64

Post by mrkgnao »

ghthor wrote: post #60
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 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 there won't be. Every community has a culture: Go's is delightfully warm, friendly, and inclusive, but also surprisingly distrustful of learning that there are easy-to-understand but powerful language features they could be using to write maintainable code without "getting a PhD in type theory from the nearest university" (to strawman a certain [type of] person [I've often encountered when arguing about these things]).

Go has done many things right (aside from the community, good concurrency and really fast compiles come to mind) but language design is not one of them.

Re: Typed nils in Go 2

#66

Post by junke »

heythere124 wrote: post #65
BlaXpirit wrote: post #55

Crystal programming language has solved the problem of nil by making it its own type and supporting ad-hoc union types. https://crystal-lang.org/api/Nil.html https://crystal-lang.org/docs/syntax_and_semantics/union_typ...

Python does that too.

Common Lisp: http://clhs.lisp.se/Body/t_nil.htm, http://clhs.lisp.se/Body/t_null.htm

Re: Typed nils in Go 2

#67

Post by BlaXpirit »

heythere124 wrote: post #65
BlaXpirit wrote: post #55

Crystal programming language has solved the problem of nil by making it its own type and supporting ad-hoc union types. https://crystal-lang.org/api/Nil.html https://crystal-lang.org/docs/syntax_and_semantics/union_typ...

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.

Re: Typed nils in Go 2

#68

Post by gondo »

masklinn wrote: post #50
gondo wrote: post #22

Earlier quoted context omitted.

"the type of an interface is nil" is that even possible?

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)

Re: Typed nils in Go 2

#69

Post by eknkc »

ghthor wrote: post #60
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 exi…

> Go is an open language

Is it, really? I haven't seen a more hostile open source project to outside ideas / requests regarding to language itself.

It's just open source.

Post reply on HN