New in Go 1.20: wrapping multiple errors • Hacker News Board

Re: New in Go 1.20: wrapping multiple errors

#31

Post by divan » Sun, Dec 11, 2022, 1:55 PM UTC

Smaug123 wrote: post #22

divan wrote: post #18

Earlier quoted context omitted.

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

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 day, and this alphabet juggling goes out of hand very quickly. Like it's unusable without constantly opening documentation pages for strfime-like functions.

I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement.

Re: New in Go 1.20: wrapping multiple errors

#32

Post by XorNot » Sun, Dec 11, 2022, 1:58 PM UTC

divan wrote: post #25

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…

This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?

Then ditch letter mapping and use named parameters: "{day} {month} {year}" etc. The Golang approach already requires complicated string parsing, so a formatting language isn't going to be more complicated, but then the documentation can just tell you exactly what you need to write to get the desired output, rather then debugging whether you got an invisible implied order wrong (with a failure mode of either giving random output, or just literals).

Re: New in Go 1.20: wrapping multiple errors

#33

Post by divan » Sun, Dec 11, 2022, 1:59 PM UTC

Smaug123 wrote: post #30

divan wrote: post #25

Earlier quoted context omitted.

This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?

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 definitely not "insane" and not "bizzare". Why would anyone even claim that?

Re: New in Go 1.20: wrapping multiple errors

#34

Post by thequux » Sun, Dec 11, 2022, 1:59 PM UTC

papito wrote: post #6

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

Exceptions reflect the realization that the proper place to handle an error is generally not where the error itself occurs. The problem with exceptions (and error returns, for that matter) is that the best place to handle an error is also not the same as the best place to decide how to handle the error.

So far, the only programming environment I've seen that makes a three-way distinction between raising, recovering, and deciding how to recover from an error is Common Lisp with its condition system[1]. However, I've successfully implemented the idea in Java using exceptions as the non-local control flow primitive, and in C using setjmp/longjmp.

[1]: https://lispcookbook.github.io/cl-cookbook/error_handling.ht...

Re: New in Go 1.20: wrapping multiple errors

#35

Post by masklinn » Sun, Dec 11, 2022, 1:59 PM UTC

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

> Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages.

Very much so. The latter is at least portable between cultures, because a month is a month, unlike "1".

And then of course you've got all the collisions like weekday (which for some reason does not follow the US standard either) or yearday, the ambiguities (like sub-seconds which can be either 0 or 9), and the outright missing fields (week numbers? week-years? No comprendo, señor..)

Re: New in Go 1.20: wrapping multiple errors

#36

Post by curling_grad » Sun, Dec 11, 2022, 1:59 PM UTC

p-e-w wrote: post #29

divan wrote: post #18

Earlier quoted context omitted.

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

Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much l…

Isn't Go more positioned as a language for web services, rather than systems programming?

Re: New in Go 1.20: wrapping multiple errors

#37

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

divan wrote: post #25

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…

This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?

> slight inconvenience for non-US citizens

So, 96% of the world's population?

And even in the US, science and engineering projects commonly use ISO dates.

Go's date formatting is as if a random American had taken a quick glance at a paper calendar pinned to the side of their fridge, and decided "yeah, let's do it like that".

Re: New in Go 1.20: wrapping multiple errors

#38

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

I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute.

I feel like a modern language should do either two things with errors: exceptions, or a result monad. Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer.

Re: New in Go 1.20: wrapping multiple errors

#39

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

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…

> 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 format is gimmicky, gimpy (it's missing a good fifth of the TR35 fields, to say nothing of the field formats), inextensible, and localisation-hostiles.

It's also telling that while Go made up this nonsense with date formats, they retained the significantly worse and more error prone printf formats for, well, printf, in case mixing the two might have been an option (as it is in python for instance).

Re: New in Go 1.20: wrapping multiple errors

#40

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

XorNot wrote: post #32

divan wrote: post #25

Earlier quoted context omitted.

This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?

Then ditch letter mapping and use named parameters: "{day} {month} {year}" etc. The Golang approach already requires complicated string parsing, so a formatting language isn't going to be more complicated, but then the documentation can just tell you exactly what you need to write to get the desired output, rather then debugging whether you got an invisible implied order wrong (with a failure mode of either giving ra…

But why? It's so handy in practice!

I work a lot with times (not just dates) and having strings like "15:04" make it immediately recognizible, consise and just right.

What I actually lack in Go's time is ability to work with time only without timezone (like, event starts at "12:00", regardless of timezone). But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others. So I just spent 10 minutes and wrote my own type for that and use it happily along with time.Time.