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

61–70 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#61

Post by kajaktum »

nvarsj wrote: post #38

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.

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

Elaborate? What prevents Go from introducing result monad aside from the syntax?

Re: New in Go 1.20: wrapping multiple errors

#62

Post by Smaug123 »

cube2222 wrote: post #45
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 li…

> I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere…

This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime will let you know loudly and fatally when you've got garbage; in a language with a type system that admits a Result type, the compiler will forbid compilation unless you note that you're throwing away the error (which might be a single character of syntactic sugar, it need not be verbose!). But Golang and C and friends are the languages where you silently get garbage if you forget to do the due diligence that machines are perfectly capable of doing for you, and it makes me extremely sad every time I see a bug of this nature.

Re: New in Go 1.20: wrapping multiple errors

#63

Post by zanderwohl »

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…

It's true... Go was supposed to be great for mission-critical stuff but the issues pop up quickly. I've seen several cases where someone migrates a Go service to Rust and like a bad dream the major problems disappear.

Re: New in Go 1.20: wrapping multiple errors

#64

Post by matwood »

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.

> the forced simplicity

I appreciate this about Go. I'm not a programming language wonk, and Go's forced simplicity makes it easier to read other people's code.

Re: New in Go 1.20: wrapping multiple errors

#65

Post by divan »

OtomotO wrote: post #48
divan wrote: post #33

Earlier quoted context omitted.

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.

Well, maybe subset of software you written or touched is much smaller than the whole set of software billions of other people wrote or touched.

Re: New in Go 1.20: wrapping multiple errors

#66

Post by cube2222 »

shakow wrote: post #42
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)…

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

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

The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language?

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

Or just use any of the popular Go code editors/plugins which give you a "show me all implementations".

In general, implicit interfaces let structures and functions require much less by defining their needed functionality subset, instead of requiring the whole "domain interface" from somewhere else.

If you have a struct that only needs to list an S3 bucket, it's nice to accept an interface that only requires listing, and not the other 30 methods the AWS library "full" interface has. This makes understanding what a piece of code is doing much easier, while simplifying mocking as well.

I do agree that enums, or even better, sum types, would be desirable. It's not a big issue in my day to day, though.

Re: New in Go 1.20: wrapping multiple errors

#67

Post by masklinn »

divan wrote: post #54
masklinn wrote: post #39

Earlier quoted context omitted.

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

> is exclusively US-centric It's literally not a problem at all. It's just one bit of information to remember in your head (I explained in a sibling comment how common US-style date in software, so for anyone who used computer longer than their last iPhone, it's just one bit of information - either date in US style or not). But with Go formatting it's even simpler - you literally never think about it. You just rememb…

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

Re: New in Go 1.20: wrapping multiple errors

#68

Post by lelanthran »

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…

> This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar.

I've been using computers since 1986, and I've used many many software packages.

Which software package uses month-day-year outside of the US? Every package uses the locale, so the 94% of the population outside of the US literally never sees this format.

Re: New in Go 1.20: wrapping multiple errors

#69

Post by masklinn »

divan wrote: post #40
XorNot wrote: post #32

Earlier quoted context omitted.

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…

> But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others.

So... why did they provide a terrible time formatting routine in the first place if it's not a solution to use cases?

Re: New in Go 1.20: wrapping multiple errors

#70

Post by zanderwohl »

p-e-w wrote: post #20
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?

The biggest mystery to me is how poorly designed Go is considering its illustrious creators. Thompson and Pike are living legends. They had absolutely nothing left to prove. Yet they came together for another major project, backed by the most powerful technology corporation in the world, and they produced... this? Go feels like a random hodgepodge of ideas from three or four computer science undergraduates – not like…

It really does feel straight out of a compilers textbook... including the suggestion to think of and add new keywords and features just for the sake of exercise.
Post reply on HN