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

New in Go 1.20: wrapping multiple errors

lukas.zapletalovi.com

Post reply on HN
Print view View original

151–160 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#151

Post by fcarraldo »

divan wrote: post #18
p-e-w wrote: post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…

There is an ISO standard for date formatting. Go ignores it, which makes interop problematic. We do get RFC3339 support, as well as a few others, but if ISO dates are being used in data being read by a Go program it’s a huge headache to ensure it will be correct using the standard library. There’s no real debate here, it was a design mistake and admitted as such.

Re: New in Go 1.20: wrapping multiple errors

#152

Post by morelisp »

Smaug123 wrote: post #98
Thaxll wrote: post #86

Earlier quoted context omitted.

And yet Go is much more popular than Rust.

… is it? For example, the Stack Overflow survey says Rust was loved by 86% of its users, while Go by 64%. Rust also beat Go on the percentage of respondents who wanted to use it. (But Golang was used by 2% more respondents than Rust, at 11.15% vs 9.32%.) https://survey.stackoverflow.co/2022/#section-most-loved-dre...

Describing that as "2% more" instead of "20% more" is a bit misleading when comparing just two items.

Re: New in Go 1.20: wrapping multiple errors

#153

Post by fcarraldo »

divan wrote: post #81
masklinn wrote: post #67

Earlier quoted context omitted.

> It's literally not a problem at all. It's just one bit of information to remember in your head Your assertions do not make that a reality. > But with Go formatting it's even simpler - you literally never think about it. True, because you quickly learn to use something else.

> Your assertions do not make that a reality What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.

> Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem

I mean, you literally got it wrong in this comment, so maybe it’s worth considering whether such a simple mistake might be hard to catch and thus cause real production issues?

Re: New in Go 1.20: wrapping multiple errors

#154

Post by hota_mazi »

ghqst wrote: post #118
lelanthran wrote: post #100

Earlier quoted context omitted.

> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…

I don't think anyone gets to say that Rust isn't popular anymore. Especially considering it's now in the Linux kernel.

And there are 1.5M lines of code of Rust in Android [1].

[1] https://www.theregister.com/2022/12/02/android_google_rust/

Re: New in Go 1.20: wrapping multiple errors

#155

Post by Smaug123 »

morelisp wrote: post #152
Smaug123 wrote: post #98

Earlier quoted context omitted.

… is it? For example, the Stack Overflow survey says Rust was loved by 86% of its users, while Go by 64%. Rust also beat Go on the percentage of respondents who wanted to use it. (But Golang was used by 2% more respondents than Rust, at 11.15% vs 9.32%.) https://survey.stackoverflow.co/2022/#section-most-loved-dre...

Describing that as "2% more" instead of "20% more" is a bit misleading when comparing just two items.

Sorry, I intended to say "2% more of the respondents". That was what I had in my mind when I wrote it. (In general, my opinion is that Relative Statistics Considered Harmful, they're like absolute statistics but with all the context removed, and I never intend to give them.)

Re: New in Go 1.20: wrapping multiple errors

#156

Post by masklinn »

foldr wrote: post #149
pjmlp wrote: post #106

Earlier quoted context omitted.

So somehow needing a language server to work around language design flaws is alright for Go then.

Sarcasm aside, I do think it’s fair to assume that someone writing code in a modern programming language in 2022 has access to basic language-aware editor tooling. That’s the beauty of the language server. You can look up the implementations of an interface from vim, or some other minimalist development environment, if that’s your bag.

"Go is so simple you don't need an IDE to write it, unlike java"

"Well obviously you need a proper IDE to protect you from Go's fuckups"

Cool.

Re: New in Go 1.20: wrapping multiple errors

#157

Post by metaltyphoon »

leetrout wrote: post #16
papito wrote: post #6

Earlier quoted context omitted.

I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposa…

Coming from Python I appreciated that there were no exceptions. I much prefer the explicit error returns instead of exceptions being used for flow control.

But thats the programmer’s fault. You shouldn’t use exceptions for flow control.

Re: New in Go 1.20: wrapping multiple errors

#158

Post by masklinn »

p-e-w wrote: post #79
cube2222 wrote: post #45

Earlier quoted context omitted.

Implicit interfaces are one of the defining features of the language that make it so great, I love them. Calling them borderline insane without any supporting arguments does make me question whether you ever gave idiomatic Go a chance. What do you dislike about them? Re error handling, I've been looking at the proposals and haven't yet seen a satisfying one. Sure, the current error handling is a bit verbose (three li…

> What do you dislike about them [implicit interfaces]? Implicitly implemented interfaces can lead to problems where you're "implementing" an interface because your methods happen to be named the same, but the functionality doesn't adhere to the contract the interface is supposed to represent. Not every contract can be described by the type system, especially not by a type system as limited as Go's. Method names like…

It also leads to easily fucking up interface implementations because that's not checked, some folks actually put "interface assertions" above the interface methods to ensure they're not forgetting anything and did not screw up any signature e.g.

    var _ Iface = (*someStruct)(nil)
will fail to compile if someStruct does not correctly and fully implement Iface.

Re: New in Go 1.20: wrapping multiple errors

#159

Post by leetrout »

metaltyphoon wrote: post #157
leetrout wrote: post #16

Earlier quoted context omitted.

Coming from Python I appreciated that there were no exceptions. I much prefer the explicit error returns instead of exceptions being used for flow control.

But thats the programmer’s fault. You shouldn’t use exceptions for flow control.

To an extent, sure, and that can apply arbitrarily to lots of things.

The Python community, by and large, embraces "easier to ask forgiveness than permission" and some features in the standard library use exceptions for their flow control. It's much more likely to run into overuse of exceptions in Python than not.

Re: New in Go 1.20: wrapping multiple errors

#160

Post by lokar »

p-e-w wrote: post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

Go explicitly prioritizes productivity in large Eng orgs with a range of programmer experience. This is often at the expense of what language enthusiasts this is important/new/cool

You may not agree, but they are doing what they said they would from the start, and it’s been fairly effective.

Post reply on HN