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

101–110 of 425 posts

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

#101

Post by justinclift »

baby wrote: post #66
sagichmal wrote: post #52

Earlier quoted context omitted.

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.

I spent years as a consultant reading codebases in different languages. I can tell you that Golang win hands down for clarity of code and structure of projects (and perhaps second after Rust in terms of security. If only it had options ...) So yeah, it's actually quite fast to dig in a Golang codebase. You notice that as a normal user when you find it faster to read the standard library vs reading the doc, or when yo…

Packages extensively using reflect + interfaces together can be a bit of a pain to work through. :/

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

#102

Post by KirinDave »

tempsolution wrote: post #55
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…

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

> It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code.

Should I compare it to "Golang Dependency Hell Claimed My Project?"

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

Why? That's not what happened with Golang's error handling?

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

#103

Post by skybrian »

parhamn wrote: post #60
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.

This isn't about good and bad, it's about experienced versus beginner, for certain values of "beginner". Not complete novices, but people who have already been programming in some other languages, but are new to Go. Think new college grads.

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

#104

Post by wybiral »

viraptor wrote: post #99
wybiral wrote: post #62

Earlier quoted context omitted.

There were multiple reasons based on my experience. New people were still using 2.7 tutorials because there was way more information out there than for 3. And package managers in Linux systems took a long time to change. But the asyncio example is probably a better example of a fundamental program design change that's causing weird fracturing and incompatible library designs. Trying to use non-async from an async fra…

I don't believe that python 2/3 change has much to do with sync/async issues. In python 2 we had twisted which was its own async universe. The sync and async worlds are disconnected in pretty much every language, but it's mostly a non-issue. You just don't mix them and it doesn't become a mess.

That's not what I said, they were two times that the community fractured.

There is fracturing with asyncio. Look at popular libraries. The "requests" library comes to mind, but there are others. It's hard to use different 3rd party components between the two paradigms which causes fragmentation in the libraries. You end up with aiohttp-requests and stuff.

PS: it does make a huge difference. If someone posts "how do I make a web server?" on a forum you'll get two different frameworks and approaches as answers. The community basically goes in two directions and much of the work becomes incompatible. The multithreaded sync vs event loop async just don't play well with each other. There still aren't many 3rd party libraries that really focus on asyncio because much of the community is still in the "threaded" design.

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

#105

Post by matthewbauer »

pcwalton wrote: post #82
unixsheikh wrote: post #63

This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software. If it ain't brok…

Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?

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

#106

Post by pcwalton »

jchw wrote: post #94
pcwalton wrote: post #91

Earlier quoted context omitted.

> Worse, everything that happens in a try block is 'flattened.' Not only does this mean you may need many try blocks, sometimes it can even be difficult to take individual statements and put them in one try block. Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semant…

>Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics. Go does not suffer from this issue at all. I am not talking about flattening from the call hierarchy, I am talking about flattening the try scope itself. (In case it isn’t obvious: in Go you’d be forced to se…

> But it results in still less cumbersome code, since you only need scoping for the error handling portions.)

There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal.

> But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated,

People say this, but in practice any code search reveals that "if err != nil { return err }" is everywhere. I believe that many Go projects aspire to annotate all errors, but much fewer actually do.

Ironically, the nice thing about exceptions, as well as Rust error chaining crates, is that they do this automatically, so in practice programs written in languages with those features tend to have better error diagnostics than Go programs do. Computers are better at doing things consistently than humans are.

> It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions.

Go is a more complex language than Java is overall, because of all the special cases the language adds to magic types like maps and errors that are just part of the library in Java.

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

#107

Post by helper »

pcwalton wrote: post #78

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.

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

I think this comes straight from the original go team. Rob Pike had a talk[1] that is partly about why go doesn't keep adding features and why it doesn't have certain features that other languages have. I think people who like go have bought into the idea that the go team has made good trade-offs to make go code easier to read and maintain at the expense of expressibility.

[1]: https://www.youtube.com/watch?v=rFejpH_tAHM

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

#108

Post by matthewbauer »

matthewbauer wrote: post #105
pcwalton wrote: post #82

Earlier quoted context omitted.

Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?

Found it: https://github.com/golang/go/issues/20803

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

#109

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]

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

#110

Post by thatswrong0 »

nkozyra wrote: post #81
baby wrote: post #66

Earlier quoted context omitted.

I spent years as a consultant reading codebases in different languages. I can tell you that Golang win hands down for clarity of code and structure of projects (and perhaps second after Rust in terms of security. If only it had options ...) So yeah, it's actually quite fast to dig in a Golang codebase. You notice that as a normal user when you find it faster to read the standard library vs reading the doc, or when yo…

> My guess is that gofmt is a huge factor in this It really is. My code looks like your code and the next person's code. Go is opinionated and strict and that makes reading other people's code so much easier

I wish gofmt would let you set a desired line length and break it for you.. prettier has me spoiled in that regard
Post reply on HN