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

41–50 of 425 posts

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

#41

Post by inlined »

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…

> errors being values

Though with generics we could have the error values be less invasive. Learning the Scala mindset was eye opening. For e.g. the design patterns of an Optional[T]’s primary code flow are the same as a Try[T,E].

With common transformation idioms, you learn to recognize code patterns the same way one might recognize data structures. It’s no less magical and it simplifies greatly.

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

#42

Post by 0815test »

CraftThatBlock wrote: post #24
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.

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

Anti-cleverness (in the 'simplicity' sense) is a feature of your coding style, not your language. And I wouldn't even describe Go as being that simple or anti-clever - this proposed feature being a case in point, with its own weirdness tacked on to it that's quite simply unknown in other, even "clever" languages.

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

#43

Post by hnaccy »

>The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

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

#44

Post by Arnavion »

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.

The `handle` is shared by multiple error branches, whereas you would have to write `match` for each one.

`Result` combinators like `and_then` only work when the error types are the same.

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

#45

Post by KirinDave »

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…

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.

So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics.

That lead to a world where folks felt "forced" to use Java, and that's a sticky label that's difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.

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

#46

Post by Thaxll »

quotemstr wrote: post #31
switchbak wrote: post #25

Earlier quoted context omitted.

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…

I agree. Go does remind me a lot of early Java. And for some domains, you do want generic easy-to-produce uncreative code of the sort Go encourages. It's just that I personally do not want to work on a project for which the technical need to repeated uncreative execution. I want to explore new ways of solving problems, and Go is not the language for that. That's why use of Go is a reliable signal.

New way of solving problems? You're in the wrong business then, programming is not about creativity.

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

#47

Post by inlined »

sagichmal wrote: post #39
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.

Go error handing _is_ fundamentally fine the way it is. That is, the verbosity would certainly benefit from some sugar, but the semantics -- errors managed by separate expressions/blocks immediately adjacent to the error-generating code -- is fundamental to the language, and one of its great strengths.

I repeatedly tell people that Go takes twice as long to write and half as long to debug. Unless you write perfect code on the first try, the trade off is probably worth it.

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

#48

Post by inimino »

quotemstr wrote: post #31
switchbak wrote: post #25

Earlier quoted context omitted.

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…

I agree. Go does remind me a lot of early Java. And for some domains, you do want generic easy-to-produce uncreative code of the sort Go encourages. It's just that I personally do not want to work on a project for which the technical need to repeated uncreative execution. I want to explore new ways of solving problems, and Go is not the language for that. That's why use of Go is a reliable signal.

There's plenty of scope for creativity at higher levels of abstraction than the translation of algorithms into programs.

Not being creative about error handling (for example) frees some of the creativity budget for things that I personally find much more interesting.

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

#49

Post by [deleted] »

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…

[deleted]
Post reply on HN