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

Declined Proposal: A built-in Go error check function, “try”

github.com

Post reply on HN
Print view View original

71–80 of 425 posts

Re: Declined Proposal: A built-in Go error check function, “try”

#71

Post by chrismarlow9 »

z0r wrote: post #38
CraftThatBlock wrote: post #24

Earlier quoted context omitted.

Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language

Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.

In my experience this is true with any language. I think this is a function of talent and program complexity (the size of the forest), not the language.

Re: Declined Proposal: A built-in Go error check function, “try”

#72

Post by pixelrevision »

curtis wrote: post #11

A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.

I don't really care about try/catch, I'd just rather they come up with a standard for wrapping errors so there is more visibility as they get bubbled up. Currently you can write code to do this but most packages will not be doing the same. There also will always be some member of your team fighting you about "simplicity" when you talk about wanting to have more info than a string to log.

Re: Declined Proposal: A built-in Go error check function, “try”

#73

Post by nkozyra »

wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

> and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem.

Is it fair to compare external packages to core language features?

There is nothing preventing a go mod/dep left-pad

Re: Declined Proposal: A built-in Go error check function, “try”

#74

Post by baby »

AnimalMuppet wrote: post #17
rbtprograms wrote: post #6

Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.

I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way. It would also appear to be amenable to an automated tool that would convert to or from try-style. Given that, why would people have strong feelings against? Because they think go…

> If anyone didn't like "try", well, don't write your code that way.

I don't have a strong opinion on try, but this is not a good philosophy. Whatever you include in a language will get used and will get abused if it can be abused.

This is mostly why there is a part of Golang users who do not want generics. Look at codebases in C++ and you can see the clarity cost of adding generics in a codebase.

Re: Declined Proposal: A built-in Go error check function, “try”

#75

Post by randomdata »

AnimalMuppet wrote: post #17
rbtprograms wrote: post #6

Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.

I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way. It would also appear to be amenable to an automated tool that would convert to or from try-style. Given that, why would people have strong feelings against? Because they think go…

> Because they think go needs something better, and if this passes, they'll never get it?

More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to forever saddle the language with even when a better way to do generics comes along.

Re: Declined Proposal: A built-in Go error check function, “try”

#76

Post by baby »

z0r wrote: post #38
CraftThatBlock wrote: post #24

Earlier quoted context omitted.

Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language

Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.

I read code for a living and Go was the easiest language to read imo.

Re: Declined Proposal: A built-in Go error check function, “try”

#77

Post by crimsonalucard »

wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

The problem with this is that code that can potentially produce errors cannot compose.

You need a value that is either correct or an error, not something that returns two values.

Re: Declined Proposal: A built-in Go error check function, “try”

#78

Post by pcwalton »

I suspected this was coming, and it's unfortunate. If Go had implemented try, then in a year everyone would be happy using it and the controversy would have died down. I've seen this happen before.

Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

Re: Declined Proposal: A built-in Go error check function, “try”

#79

Post by baby »

switchbak wrote: post #25
quotemstr wrote: post #13

With try, Go might have been a language I'd have enjoyed using. It's a shame. Right now, I see Go as being anti-abstraction and anti-cleverness, and I'd rather not work on codebases in which the language of choice is designed to deter creativity and encourage monotony. Heavy use of Go is a big negative when I evaluate potential projects to work on.

I think that's quite on purpose - a lot of folks seem to look down on 'clever' code. I think at its extreme we can almost all agree that hyper-clever code is a bad thing. I think we just differ on where that threshold starts for every day code. Apparently (early) Java was designed in much the same way, just to a lesser degree. I'm not a fan of languages specifically designed to limit me from expressing myself. Then a…

Even if you work on small teams, you use dependencies.

Re: Declined Proposal: A built-in Go error check function, “try”

#80

Post by MaulingMonkey »

0815test wrote: post #30
MaulingMonkey wrote: post #19

Earlier quoted context omitted.

In the draft design, they give an example of special-case cleanup that would only execute only when an error occurs , not on the success path. You can emulate this with a boolean flag in your RAII types in Rust or C++, that's set or cleared immediately before a successful return, and then doing conditional logic in your Drop/dtor. Or you could do a std::mem::forget before successful returns. But I guess they think th…

> execute only when an error occurs You can use the match construct for that, and the Result type comes with some utility methods that make it easier to clarify your desired semantics in many cases. The page complains that the "match" syntax is clunky, but I'm not that sure how 'handle' is supposed to be better.

As Arnavion points out, handle handles multiple error cases. That said, I'm not convinced it's better in practice. For some comparison points - here's how I'd write the Go CopyFile in Rust:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Or, if we want to keep a more 1:1 direct mapping to the Go code:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Caveats with the "1:1" mapping:

1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type. I've tried to mimic the Go code here, not fully convert to Rust idioms.

2) You could get rid of the .as_ref() spam by just using &str or &Path to be closer to the Go code, but I'd rather stick at least that close to std::fs::copy's file signature.

3) All explicit close operations are dropped as unnecessary vs the Go code. I guess I could've used std::mem::drop to be more explicit?

4) TempPath is obvious overkill for the single remaining error point

5) In temp-file heavy code you'd probably wrap TempPath + File into TempFile. keep could return the interior File as well.

Post reply on HN