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

91–100 of 119 posts

Re: Typed nils in Go 2

#91

Post by mrkgnao »

laumars wrote: post #89
mrkgnao wrote: post #82

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

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

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better.

https://rustbyexample.com/std/result.html

Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.

The reason I participate in HN comment threads about Go is largely how entertaining I find comments strenuously rationalizing Go's inadequacies. In one (very recent but definitely memorable) case[1], I was told that

> You [should] first reconsider your need to make a generic data structure and evaluate on a case by case basis.

[1]: https://news.ycombinator.com/item?id=14970919

Re: Typed nils in Go 2

#92

Post by laumars »

mrkgnao wrote: post #91
laumars wrote: post #89

Earlier quoted context omitted.

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

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better. https://rustbyexample.com/std/result.html Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.…

I didn't say ergonomic error handling nor generics et al were Haskell methodologies. I'm saying you keep coming into Go threads just to troll that Go isn't as good as Haskell. This isn't even the first thread this week you've been making Haskell vs Go comparisons.

Re: Typed nils in Go 2

#93

Post by mrkgnao »

laumars wrote: post #92
mrkgnao wrote: post #91

Earlier quoted context omitted.

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better. https://rustbyexample.com/std/result.html Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.…

I didn't say ergonomic error handling nor generics et al were Haskell methodologies. I'm saying you keep coming into Go threads just to troll that Go isn't as good as Haskell. This isn't even the first thread this week you've been making Haskell vs Go comparisons.

Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example".

(I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)

Re: Typed nils in Go 2

#94

Post by augustk »

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"?

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

Oberon is an example of a true lean programming language. The complete language reference takes up only sixteen A4 pages. The compiler OBNC implements the latest version of the language:

http://miasap.se/obnc/

Re: Typed nils in Go 2

#95

Post by laumars »

mrkgnao wrote: post #93
laumars wrote: post #92

Earlier quoted context omitted.

I didn't say ergonomic error handling nor generics et al were Haskell methodologies. I'm saying you keep coming into Go threads just to troll that Go isn't as good as Haskell. This isn't even the first thread this week you've been making Haskell vs Go comparisons.

Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example". (I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)

I made the edit because on reflection the part i took out was blunt and unnecessary. I felt I crossed the line so I apologize for that.

Re: Typed nils in Go 2

#96

Post by dullgiulio »

mrkgnao wrote: post #90
dullgiulio wrote: post #86

Earlier quoted context omitted.

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) } you can just use an optional ("Maybe") type: write a, b, and c…

That's right. But I prefer to decorate each error as it comes back from the callee, writing what I was trying to do that failed. This gives a human readable trace of the problem, and also a unique signature for the error itself.

Re: Typed nils in Go 2

#97

Post by masklinn »

dullgiulio wrote: post #78
gondo wrote: post #68

Earlier quoted context omitted.

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…

> My question is: what are the legitimate use cases for interfaces that are half-nil?

I think that's two different questions:

* Is there a legitimate use case for nil not being nil? I don't think so.

* Is there a legitimate use case for having "typed nil" interfaces? Kinda, Go supports and encourages calling methods "with nil receivers", and doing that through an interface requires that the concrete type (the non-nil half) be conserved otherwise you can't dispatch the method call.

Re: Typed nils in Go 2

#98

Post by masklinn »

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…

> Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article.

Not really, Go supports (and encourages properly handling) nil method receivers.

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

Setting aside the fact that this is not quite true[0], there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state and possibly but not necessarily faulting at some other point later on. PHP gets regularly and deservedly panned for the latter.

[0] nil is a message-sink in obj-c (any message can be sent to nil and will be a no-op returning nil), and you can make Ruby or Smalltalk behave that way (or any other) as their nil is a regular object with a normal type which you can go and extend

Re: Typed nils in Go 2

#99

Post by masklinn »

dullgiulio wrote: post #96
mrkgnao wrote: post #90

Earlier quoted context omitted.

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) } you can just use an optional ("Maybe") type: write a, b, and c…

That's right. But I prefer to decorate each error as it comes back from the callee, writing what I was trying to do that failed. This gives a human readable trace of the problem, and also a unique signature for the error itself.

> But I prefer to decorate each error as it comes back from the callee

That's trivially feasible and still shorter than the Go version:

    a
Outside of the do context, your return value is just that, a value, you can manipulate it using the language's regular tooling. And you can decorate the do context itself if you want the same decoration for all calls in the block.

Re: Typed nils in Go 2

#100

Post by ZGF4 »

pyrale wrote: post #18

Gotta love how the initial problem (a typed language in the 2000s having nil and empty interfaces) degenerates in workaround suggestions such as hacking nil and the interface system to give it a special type.

It is interesting how Go seems to be doomed to head down the same path as other languages it accused of being "bloated." No one intends to design a complicated language but the reality is that the problem space is complicated.

The only thing that isn't so forgivable with Go is that these aren't new problems this time around. Go is still struggling to get over challenges that were first seen a long time ago. It's a great experiment on designing for complexity vs trying to avoiding complexity.

Post reply on HN