New in Go 1.20: wrapping multiple errors

Post by p-e-w » Sun, Dec 11, 2022, 2:07 PM UTC

bstpierre wrote: post #23

foldr wrote: post #12

Earlier quoted context omitted.

Isn't this line of argument somewhat self-defeating? It sounds as if these language design decisions that cause a vocal minority to complain loudly have only a marginal impact on actual productivity (or at least the perception of it). If so, that would be quite a good justification for not complicating the language by, e.g., adding enums, a non-nil pointer type, etc. etc.

I think that what you’re talking about might even be the killer feature that is often ignored: the forced simplicity. It’s a simple enough language that you can drop into a codebase and read without having to look up much syntax, assuming you have some familiarity with c-family languages. Yes, there are some weird bits that you have to learn, but the learning curve is very short compared to a lot of other languages.

Post by divan » Sun, Dec 11, 2022, 2:08 PM UTC

masklinn wrote: post #39

divan wrote: post #31

Earlier quoted context omitted.

With both approaches you have to remember some sort of mapping technique for date formatting. What I claim that Go's approach is far superior and easier to remember and use. Leaving aside "oh, but we used to letters" thing, one of the problems with letters is that it's just o much stuff to remember and it only grows as you use more than one languages on a daily basis. I sometimes switch between 4 languages during the…

> What I claim that Go's approach is far superior and easier to remember and use. [...] I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement. The Go approach is barely "more efficient" if your only consideration is exclusively US-centric, it's outright hell everywhere else, because US date formats make even less sense than their units. Go's datetime f…

Post by sidlls » Sun, Dec 11, 2022, 2:09 PM UTC

sylens wrote: post #4

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…

I’m glad it’s not just me who is perplexed at some of the decisions made with golang. This was a golden opportunity to implement some typical form of exception handling. Instead you have to bundle your errors together and then unwrap them (often using multiple methods to handle the cases of both a single error and a bundle of errors) and then still implement even more logic to walk the tree you made?

Post by nhooyr » Sun, Dec 11, 2022, 2:10 PM UTC

sidlls wrote: post #51

"What only matters is the unwrapping procedure and conversion to string because that is what is needed." This, in a nutshell, encapsulates what Go gets wrong about error handling. The simplicity is great; the extreme simplicity at the expense of runtime efficiency and clarity is not . Errors are not just strings . They can (and should) encode information, and the language should support that efficiently. And the mech…

Post by lelanthran » Sun, Dec 11, 2022, 2:11 PM UTC

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…