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

211–220 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#211

Post by lokar »

hocuspocus wrote: post #208
lokar wrote: post #160

Earlier quoted context omitted.

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.

Eschewing industry standard ergonomics that have been taught to every developer for the past 3 decades seems like the total opposite of "prioritizing productivity" to me. Besides, in large engineering organisations you're always going to find multiple languages. Even at Google, which keeps a very short list of blessed languages compared to most companies, the Googlers I know who typically work on "proto to proto" mid…

At google it mostly displaced uses of C++ and python

Re: New in Go 1.20: wrapping multiple errors

#212

Post by Rapzid »

morelisp wrote: post #184
Rapzid wrote: post #15

Earlier quoted context omitted.

Something about needing to use fmt.Errorf to JOIN errors if you want custom string formatting rubs me the wrong way. I had to read that section twice because it completely went over my head it acting as a join.. So unexpected for fmt to be doing error biz like that.

> needing to use fmt.Errorf to JOIN errors if you want custom string formatting You don't need to, you can implement Unwrap yourself and format the error however you want, just like singular errors today. > unexpected for fmt to be doing error biz like that. IIRC, this has to do with avoid circular package dependencies. fmt can depend on errors (and quite a lot of other stuff) but errors can't depend on fmt, so eithe…

> You don't need to, you can implement Unwrap yourself and format the error however you want, just like singular errors today.

Sure, but when discussing the language stdlib design being able to reimplement myself isn't particularly germane. It's what is provided that's being criticized.

> IIRC, this has to do with avoid circular package..

The journey to the bad design is interesting, but here we are haha.

IMHO it's weird (poor design) to have fmt as the place to join errors if we want to customize the string.

The article tries to make the case that errors ARE just strings, but I don't buy what it's selling. The type checks in Is and interface casting in Unwrap are my counter arguments.

Re: New in Go 1.20: wrapping multiple errors

#213

Post by rmrfchik »

divan wrote: post #197
rmrfchik wrote: post #137

Earlier quoted context omitted.

I thought it was a joke about mnemonic, until realized you're serious. This is NOT a mnemonic, because it lacks either rule like each next component gives more specific time, or external reference like poem or image. It can be easily substituted with 1st year, 2nd day, 3rd hour, 4th minute, 5th second, 6-th month, 7th timezone.

mnemonic is just a memory aid, it can be anything. if you prefer other term, feel free to use it, but the point still holds - it's a 1234567-based date that you remember once (most people can do it) and it helps remembering what should be in the format string.

What is 1234567 anyway? Why 1 is month? From which clue should I remember that?

Re: New in Go 1.20: wrapping multiple errors

#214

Post by [deleted] »

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…

[deleted]

Re: New in Go 1.20: wrapping multiple errors

#215

Post by [deleted] »

kaba0 wrote: post #190
p-e-w wrote: post #20

Earlier quoted context omitted.

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…

They are living legends, but they are not good at language design. C is not a well-designed language either.

[deleted]

Re: New in Go 1.20: wrapping multiple errors

#216

Post by erik_seaberg »

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 bigger the toolbox is, the more becoming an expert pays off. I would much rather fully learn a language I’m using as a working professional, than have to review many home-grown solutions to a common problem the language ignored.

Re: New in Go 1.20: wrapping multiple errors

#217

Post by [deleted] »

divan wrote: post #210
masklinn wrote: post #35

Earlier quoted context omitted.

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

Very much so? Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.

[deleted]

Re: New in Go 1.20: wrapping multiple errors

#218

Post by masklinn »

XorNot wrote: post #43
kasey_junk wrote: post #24

Earlier quoted context omitted.

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.

Fwiw lots of folks dislike m[K]struct{}, because while it’s efficient checking for presence is horrible:

    _, present = m[k]
It looks weird and is not an expressions. Obviously you could paper over this with a dedicated builtin function but that’s not great.

A common alternative is m[string]bool, memory density is worse but contains/add/remove are easier to read and more convenient.

Re: New in Go 1.20: wrapping multiple errors

#219

Post by lzap »

Rapzid wrote: post #28
leetrout wrote: post #17

Earlier quoted context omitted.

Especially given the current landscape of log handling as the author points out. I am all in on structured logging most of the time and I don't want to have to deal with a newline causing multiple records in my log aggregation.

It's also not true the interface for Unwrap() doesn't exist; behold https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/... ... Yeah, it's not exported but...

In the blogpost I specifically wrote "There is no (named) interface in the standard library..." because I was aware of the function you point out. Rather than unexported interface, I would probably call that an "anonymous interface".

Anyway, now that I read that, I should probably skip this fact and just keep the example interface. It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency).

Re: New in Go 1.20: wrapping multiple errors

#220

Post by lzap »

candiddevmike wrote: post #5

I still don't see a benefit with this over custom error types. Having a huge switch statement to determine the HTTP response code seems really inefficient vs just doing errors.As and getting the response code directly.

As I said in the article, the example is simplified. As you point out, incorporating the HTTP code into the error and using errors.As is much better way of doing that:

"Obviously, the common HTTP status codes could easily be a new error type (based on int type) so the actual code could be easily extracted via errors.As, but I want to keep the example simple."

Post reply on HN