Anyhow's tagline is literally "a better Box<dyn Error>", which gets you nearly the same result modulo some pretty printing.
Yes, Anyhow is almost as easy to use as Go's current error handling.
You're significantly more experienced than me, so I'll defer to you here. What you're saying doesn't make sense to me though.
You're probably more experienced than I am with Rust!
I might be misunderstanding go, but I think the big difference is you use anyhow to get looses error handling at the edges of binaries. It'd be weird to see in a published library, and unusual to see deep in an internal library that supports a binary. Whereas in go you do that sort of error handling everywhere.
I think %w makes sense in libraries, too. They're structured errors that behave like strings. It's a neat trick.
Re:Down the Golang Nil Rabbit Hole
by tsimionescu on Tuesday March 30, 2021 @05:30AM
(#26632640)
Most errors in Go are still just strings, potentially with some comparison possible witht sentinel values like in the "io" package. As and Is give some nice tools, but its still up to documentation to decide which one to use, and different packages have different conventions for returning error types vs error values.
Most errors are probably strings since there probably is nothing you can customize as a handling for such particular error types. Now, if one could do something with a certain error class, then such error are usually not strings.
Errors in modern Go are definitely not just strings.
Before wrapped errors in Go, this would have been an easier case to make against the language.