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

131–140 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#131

Post by cesarb »

ghqst wrote: post #118
lelanthran wrote: post #100

Earlier quoted context omitted.

> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…

I don't think anyone gets to say that Rust isn't popular anymore. Especially considering it's now in the Linux kernel.

Playing devil's advocate: what's now in the Linux kernel is the infrastructure to allow writing code in Rust, but AFAIK for now nothing uses it (there's Asahi Lina's Rust driver for the Apple M1/M2 GPU, but it's still out-of-tree).

I find it likely that Rust in the Linux kernel will not be used for anything important (other than architecture-specific code) until either it can be compiled using GCC (either the GCC backend for the Rust compiler, or the Rust frontend for the GCC compiler), or the LLVM backend supports every single architecture supported by the Linux kernel (or the Linux kernel loses support for the architectures the LLVM backend doesn't support).

Re: New in Go 1.20: wrapping multiple errors

#132

Post by hellcow »

peacelilly wrote: post #121

The secret to wrapping errors is the erros.As and errors.Is special interfaces called out only in the documentation: https://pkg.go.dev/errors#Is You must build a Directed Acyclic Graph (DAG) to ensure these special interfaces don't hit an infinite loop. To stop the infinite loop cycles, and actually implement a DAG, I marked visited nodes and returned `false` if the nodes were already marked.

If you’re needing to implement this I’d highly suggest your code could be restructured to eliminate the issues. This is a code smell.

I’ve been using errors.Is since day one and have never once needed to implement anything like you described. I define sentinel errors in my root “business logic and types” package, and my child packages use those special errors in their own error Is() methods.

Re: New in Go 1.20: wrapping multiple errors

#133

Post by vlunkr »

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…

The conversation around Go on HN is as broken as a political discussion on Facebook. It’s pathetic.

Re: New in Go 1.20: wrapping multiple errors

#134

Post by liveoneggs »

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…

> transitioning from Python ... the true "one way to do it" philosophy

I love this :)

Re: New in Go 1.20: wrapping multiple errors

#135

Post by gilbetron »

nprateem wrote: post #107

I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?

That's exactly the language I want as well. A mashup of Go and Rust that keeps the best of both. Also, don't forget "compiles fast"! And the garbage collector, although I'd love a language that allowed me to handle memory as well.

Re: New in Go 1.20: wrapping multiple errors

#136

Post by Lev1a »

cesarb wrote: post #128
p-e-w wrote: post #92

Earlier quoted context omitted.

Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.

> Rust doesn't have nil/null values. I have to nitpick here: Rust raw pointers ( https://doc.rust-lang.org/std/primitive.pointer.html which does note "Working with raw pointers in Rust is uncommon") do have null values. It's not usually a problem since raw pointers can only be dereferenced in unsafe code; most of the time, you will be using a reference wrapped with an Option, which has the same size and same possible…

> since raw pointers can only be dereferenced in unsafe code

Sure, and "unsafe" is not only a huge red flag but can and should be tightly scoped and can then be audited much easier than chasing around NPE through an entire Class or even codebase.

Secondly, I've used Rust for a few years now and have NEVER needed to or thought of using raw pointers once. It's unnecessary for almost every single usecase I can think of except maybe OS or driver development but even then you can tightly control where "unsafe" uses pop up.

Re: New in Go 1.20: wrapping multiple errors

#137

Post by rmrfchik »

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

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.

Re: New in Go 1.20: wrapping multiple errors

#138

Post by hellcow »

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.

It’s very useful when multiple errors happen concurrently, like collecting errors from separate goroutines after they all finish.

Re: New in Go 1.20: wrapping multiple errors

#139

Post by sethammons »

shakow wrote: post #110
bamboozled wrote: post #77

Earlier quoted context omitted.

Sorry, but what are you talking about? Poorly designed? A lot of incredibly good software is written in Golang and while that might not mean it's the best language ever designed, it would be hard to say it's "poorly designed" based on that fact alone?

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.

Re: New in Go 1.20: wrapping multiple errors

#140

Post by cesarb »

727564797069706 wrote: post #120

I once liked Go a lot, then over time got frustrated by few things and moved on. Now I'm all about "Rust is the best thing since sliced bread!" I find it a bit hard to understand why people are critizing Go "yaddayadda oh how wrong this decision is yaddayadda" . Like, who cares. Let them do how they like it. Nobody is forcing anyone to use the language. Go's design decisions are not a universally applicable law or an…

> I find it a bit hard to understand why people are critizing Go "yaddayadda oh how wrong this decision is yaddayadda". Like, who cares. Let them do how they like it. Nobody is forcing anyone to use the language.

A choice of programming language affects people other than the ones who decided on it. An obvious example is bug fixing and other maintenance; if for instance I find a bug in syncthing and want to fix it, I have to learn Go, because that's the programming language they chose. Another example is finding work; if most employers have systems written in Java, and you don't want to be picky about it, you have to learn and use Java. And finally, the popularity of a language directly affects its ecosystem's health, and since there's a limited amount of programmer time in the world, one language becoming more popular implies other languages become less popular (and after some point, their ecosystems begin to suffer).

Given all that, it makes sense that even people who do not like Go want its designers to make good choices (and get annoyed when they make bad choices), since its popularity means that there's a good chance that they will have someday to use it.

Post reply on HN