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

51–60 of 425 posts

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

#51

Post by wybiral »

KirinDave wrote: post #45
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 sti…

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

Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP.

Edit: As a fun tangent... Python experienced the same kind of fracturing that adding generics or other dramatic features to a language can cause with the 2to3 move. There are still projects based on 2.7. It was hard to get people all on the same page once the community was split. What's also interesting is to watch the same thing happen with asyncio, which is practically an all-or-nothing thing to use in your Python project, so much so that most Python code still doesn't use it. Just an observation, but breaking changes to a language can really do a number on the community.

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

#52

Post by sagichmal »

inlined wrote: post #47
sagichmal wrote: post #39

Earlier quoted context omitted.

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.

That feels about right, but missing the most important measure, IMO, which is it takes 10-100x less time to read and understand a new codebase.

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

#53

Post by [deleted] »

libria wrote: post #23
kjksf wrote: post #12

Earlier quoted context omitted.

They listened to the part of the community that agrees with you. I'm "community" and I would prefer to have `try()` than not to have. They didn't listen to me.

"Listened to" is colloquial for "engaged with". They engaged with people who represented the `try()` option and declined to implement it. It is impossible to implement every proposal their ears listened to so obviously that's not what listened means.

[deleted]

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

#54

Post by patientplatypus »

I mean...

If you don't like writing `if err!=nil {...}` throughout your code base surely you can just create some middleware function in its own package that has switch statements based on error cases. Checking for errors frequently in the running of the code is more or less a Good Thing.

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

#55

Post by tempsolution »

KirinDave wrote: post #45
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 sti…

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code.

For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actually have been a viable design. Littering your code with try-catch is what makes exceptions infeasible for error handling.

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

#56

Post by KirinDave »

wybiral wrote: post #51
KirinDave wrote: post #45

Earlier quoted context omitted.

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

> 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. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that…

I don't think folks are on 2.7 because they love it. I think they're there because it's difficult and expensive to migrate Python code.

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

#58

Post by unscaled »

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…

Java-the-language was designed to be anti-clever, but a decade later, most code written in it ended up being the epitome of hyper-cleverness.

Lack of abstractions (a.k.a "cleverness") on the language level, pushed developers to abstraction on the code level, often based on reflection and supported by XML files and (later) annotations.

In retrospect, by avoiding cleverness in Java, we ended up with multiple incompatible framework dialects which implement their own cleverness.

Go avoided this fate so far by having weaker support for reflection, and since the collective developer memory of Java framework excesses is all too fresh. This makes Go code more readable than Java on average, but I don't think it's any more readable than idiomatic code in a high-abstraction language like Rust, Kotlin or Swift - once you learn and internalize how these languages work.

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

#60

Post by parhamn »

hnaccy wrote: post #43

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

The average skill of most software teams is probably not far if not lower. I've been on very good ones and very bad ones -- lots of the code becomes least-common-denominator/weakest-link quality.
Post reply on HN