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

41–50 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#41

Post by masklinn »

p-e-w wrote: post #11
tejinderss wrote: post #9

Earlier quoted context omitted.

> everything from TLS to CSV is rolled into std without ever having to import a third-party repository And yet the std library is missing some basic data structures like Set.

Because they can't be properly implemented without generics, and generics were only shoehorned into Go a decade after its initial release.

They could be implemented as builtins, like channels, slices, and maps were.

Though what's really missing is generic set functions, and a decision as to which "hashmap shape" is the blessed set (between map[T]struct{} and map[T]bool), a "set" builtin can just be an alias to that in the same way "any" is an alias for "interface{}".

Re: New in Go 1.20: wrapping multiple errors

#42

Post by shakow »

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

> which start make sense as long as you use them and put some thought behind the reasons of the design

Hard disagree. I have been using Go at my company for years, and these features still make no sense to me.

> lack of enums

Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basically C #define. And I think that the consensus has been, for decades, that having badly typed magical constants was not a good thing.

> implicit interfaces

Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM.

> by popular urban myth

Tell me exactly who finds that nil pointers are a great thing in a high-level language?

Re: New in Go 1.20: wrapping multiple errors

#43

Post by XorNot »

kasey_junk wrote: post #24
p-e-w wrote: post #11

Earlier quoted context omitted.

Because they can't be properly implemented without generics, and generics were only shoehorned into Go a decade after its initial release.

The go language has had generics since inception, just not user defined ones. If they wanted a set data structure they could have had it like they do maps and slices.

Set is just a Map though where you don't care about the values.

var m[string]struct{} implements this for you.

What you're really missing is the usual suite of helper methods which make sets ergonomic - and for that you need proper generics.

Re: New in Go 1.20: wrapping multiple errors

#44

Post by [deleted] »

divan wrote: post #31
Smaug123 wrote: post #22

Earlier quoted context omitted.

The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time : > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it…

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…

[deleted]

Re: New in Go 1.20: wrapping multiple errors

#45

Post by cube2222 »

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…

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 lines after each erroring function call), but it's a completely irrelevant problem to me in my day to day, and I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere.

In general, I like the approach of the Go team of only accepting proposals that are good and actually widely requested, as opposed to accepting "something" because "our story for this isn't great to some".

Re: New in Go 1.20: wrapping multiple errors

#46

Post by fideloper »

imiric wrote: post #27

I guess it's become trendy to hate on Go in this forum, so I'll offer a counterpoint. Being a relative newcomer to the language, transitioning from Python circa 2016, I've found it a joy to use. The simplicity of the spec, the true "one way to do it" philosophy, the way it forces you to simplify and avoid cleverness (yes, sometimes at the expense of verbosity, which only makes things clearer, and rarely tedious), the…

Looks like that specific issue / change wasn't accepted, but this[1] alternative will be.

That seems like a great change to me.

[1]: https://github.com/golang/go/issues/51365

Re: New in Go 1.20: wrapping multiple errors

#47

Post by fourseventy »

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…

That's just your opinion. I love the error handling in go and I believe it is a vocal minority that complain about the error handling on hn.

Re: New in Go 1.20: wrapping multiple errors

#48

Post by OtomotO »

divan wrote: post #33
Smaug123 wrote: post #30

Earlier quoted context omitted.

Do you have a source for that statement? (For all I know, you are a member of the team who wrote it, so you may know what it means! I certainly had nothing to do with its writing.) To me, the statement is obviously saying "yeah this order is just bizarre, why on earth did we put the two most significant digits around the outside of the rest, good luck".

I'm not a member of a Go team. I can comment though as a non-US citizen. This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. Like most of the software historically was born in US, and it's just a very common case where localization is not respected and you see american style dates every now and then. It's getting better, but still, not unusual. While it's different from european…

It's not common in any software I've written or touched in my entire career.

Re: New in Go 1.20: wrapping multiple errors

#49

Post by qsort »

Thaxll wrote: post #19
sylens wrote: post #4

Earlier quoted context omitted.

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?

Exception handling sucks, stop asking for it. Did you worked in Java? Did you worked with async and exceptions?

I work in Java every day and I'll take exceptions any day over... that. I have a lot of respect for the engineering work the Go team put into the compiler, toolchain and stdlib, it's truly commendable. But the language itself is frankly a step back form everything else on the market today.

Java, C#, hell, even python are better designed languages than Go.

Re: New in Go 1.20: wrapping multiple errors

#50

Post by ovao »

kasey_junk wrote: post #26
Thaxll wrote: post #19

Earlier quoted context omitted.

Exception handling sucks, stop asking for it. Did you worked in Java? Did you worked with async and exceptions?

Where did the poster ask for exceptions? And golang has them in the form of panics and they suck in goroutines.

> This was a golden opportunity to implement some typical form of exception handling.
Post reply on HN