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

181–190 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#181

Post by za3faran »

cube2222 wrote: post #111
shakow wrote: post #90

Earlier quoted context omitted.

> The language has static type-checking. No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. > Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". Does not work all the time, hence my use of the ‶rickety″ adjective. > This makes understanding what a piece of code is…

> That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them. It really isn't. This way it becomes a guessing game "Which methods will be used with which other ones?". Even if I have a KVStore interface with 4 methods: Get, Set, List and Delete, it's a huge…

> it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete.

But that's not specific to golang. You can use the same approach in Java, Kotlin, C#, etc

Re: New in Go 1.20: wrapping multiple errors

#182

Post by za3faran »

pjmlp wrote: post #88
cube2222 wrote: post #66

Earlier quoted context omitted.

> 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 use any of the popular Go code editors/plugins which give you a "show me all implementations". And me thinking the Go culture is against languages that tend to come with IDEs...

Not to mention how slow it becomes in large projects

Re: New in Go 1.20: wrapping multiple errors

#183

Post by metaltyphoon »

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…

> I can't wait for what v2 will bring

There is no such thing as V2

Re: New in Go 1.20: wrapping multiple errors

#184

Post by morelisp »

Rapzid wrote: post #15
donatj wrote: post #2

Given the now two interfaces, Unwrap() error and Unwrap() []error I really wish they had just done only the latter since the beginning. Continuing to have and support the prior feels like a mistake somewhat permanently baked into the language. I know it is easy to armchair second guess but one of the very first things I tried when they added wrapping a couple versions ago was wrapping multiple errors. I am reasonably…

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 either a) errors needs to implement its own format string processing, b) a wholly new errfmt package is introduced, c) fmt.Errorf.

Re: New in Go 1.20: wrapping multiple errors

#185

Post by kaba0 »

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…

I mean, how often do you have to parse that part of the code? If it is everywhere, you should start writing helper functions or some other abstraction.

In my opinion this is typically a very static part of code bases, it is written correctly once (where you can look at the documentation all day long) and possibly never ever looked back on.

Re: New in Go 1.20: wrapping multiple errors

#186

Post by kaba0 »

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…

> compared to its most direct competitor, Rust.

No, no, no and no. How on Earth people come to this conclusion? Go is closer to node.js than to Rust. Like, it is not even a competition they are so far apart. One is a “zero-cost abstraction, low-level language”, the other is a “managed language with a GC like million others, which is as badly expressive as C”. To mention some positive as well, virtual threads are cool.

But the two is nothing alike and this sentiment is just utterly stupid and I see it everywhere for God knows why.

Re: New in Go 1.20: wrapping multiple errors

#187

Post by za3faran »

sethammons wrote: post #139
shakow wrote: post #110

Earlier quoted context omitted.

Incredibly good software has been written in JS, that does not make a good language out of it. To a competent team, a bad language is an hindrance, not a deadly obstacle.

The difference is options. Developers can use anything on the back. You are stuck with JS on the front. That devs _choose_ Go means something.

You'd be surprised that the answer in a lot of times cooties just be hype or inertia. I've seen it first hand at an employer that supported both Java and golang. A new project was started in golang just because of inertia, whereas Java would have been a strictly superior choice on basically every front. The resulting code base was a huge mess, even as per the admission of the "lead" who made the original decision, who clearly had no business making that decision in the first place. Literally over a million dollars spent on a mediocre, unmaintainable result

Re: New in Go 1.20: wrapping multiple errors

#188

Post by kaba0 »

cjglo wrote: post #129
Smaug123 wrote: post #62

Earlier quoted context omitted.

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

I don’t like Go error handling, but exceptions are terrible and not better. Rust/Zig/Swift approach is definitely the best.

Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).

Re: New in Go 1.20: wrapping multiple errors

#189

Post by henry_viii »

richbell wrote: post #162
henry_viii wrote: post #143

Earlier quoted context omitted.

I think something like V is what you're looking for: https://vlang.io/

Perhaps V will be suitable for writing production systems one day. Until then, it doesn't seem suitable for anything outside hobby development.

To be clear, I wasn't telling GP to go and write production systems in V. Even though V has stabilized a lot by now, it's still a pre-v1.0 language and with that it carries potential risks.

I suggested to GP to take a look at V, though, because V has a Go-like syntax + it has everything GP is looking for.

Re: New in Go 1.20: wrapping multiple errors

#190

Post by kaba0 »

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…

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