Comment by grose | Hacker News Reader

Comment by grose | Hacker News Reader

I love weird little experiments like this! I was in favor of the check-handle proposal[1] that landed at the same time as the generics proposal and a little sad that it seems to be abandoned.

Bikeshed: How about _two_ bangs?

        data := !!io.ReadAll(zd)

The double-bang pattern is unused in Go because it doesn't coerce non-booleans to booleans, so you can appropriate it without stepping on anyone's toes :)

The main disadvantage of a Rust-?-like syntax for Go is you lose the ability to add context to the error (e.g. wrapping with `fmt.Errorf("context goes here: %w", err)`). Some people prefer to shove a stack trace inside the error to work around this. I'm not sure what the perfect solution would be. The check-handle proposal adds a special handle keyword to deal with it.

BTW, I am aware of the 'errors are values' concept -- I was the guy interpreting for Rob Pike and the nice Japanese fellow who asked him about it at a conference afterparty and inspired the blog post. I think this pattern is great but it's quite hard to distill it into generic advice ("delay reporting errors until the last possible moment"?). Designing ergonomic APIs for Go can be challenging, and purely anecdotally a lot of the proprietary Go code I've seen at various companies does not do a great job at it.

My #1 wish for Go is that one day Go will figure out sum types and pattern matching. I know that the way interfaces work make this challenging, but I have hope. Using sum types to handle errors makes it much more obvious what the 'right thing' to do is.

[1]: https://go.googlesource.com/proposal/+/master/design/go2draf...

> The main disadvantage of a Rust-?-like syntax for Go is you lose the ability to add context to the error

You don't lose the ability to just by that syntax existing. You could still do so by writing it out the long way like you have to do anyway today in Go.

Indeed. What I meant is that compared to the pre-existing error handling, there are use cases it won’t fit. I am pro-? syntax. I think it would be useful even without being able to add context, but I’m also interested to see if there are solutions that could handle this for you.

? is short syntax for something nobody should ever do. Why add special syntax for something you should literally never do?

And why should nobody ever do that?

There's also helper crates like eyre simplifying the process of adding context even further (at the cost of type erasure):

    foo().context("oh no")?

What do you mean by "at the cost of type erasure"? Isn't type erasure an attribute of a programming language and not something that a library has control over?

In this case, it means your actual error will be packed and boxed someplace behind a smart pointer, its type will be lost (so you wouldn't be able to match on its specific variants downstream might you want to) but it will be still able to format itself to a string and will comply with std::error::Error trait.

It could be something like

    data := io.ReadAll(zd) ?: return nil, fmt.Errorf(...)

like in Kotlin. I think this likes to encourage overly-long lines though, I'm personally happy with Go's error handling today.

Oh yeah, I’m not seriously suggesting !! as a new language feature, just recommending it as an alternative to the article’s (!fn() and ^fn()). The reason for “abusing” these pre-existing syntaxes is so that you can take advantage of the official parser and AST package. Makes it easier to play around with. If Go were to ever actually add this feature, they definitely should use a new keyword or symbol.

Reply on news.ycombinator.com