[iamsomewalrus]

I use Go as my preferred language and I think the author is mostly right.

There’s no way for me to know or even check what are the possible errors this function can return? Sure, sometimes a comment in the library might be illuminating, but sometimes not.

I agree that errors as values that I can handle at the call site rarely feel useful.

Some of the Is, As ergonomics have improved, but damn if coding agents don’t love to just fmt.error any code it writes. Thus hiding the useful information about the error in a string.

[tptacek]

The article claims:

"The user now has an interface value error that the only thing they can do is access the string representation of."

This is false. Didn't used to be, but that was many years ago.

[benrazdev]

>this is false.

It's mostly false.

Technically, if you use `fmt.Errorf`, then the caller can't get anything useful out of your errors.

Types are promises. All the `error` interface promises is a string representation. I acknowledge that most of the time there is more information available. However, from the function signature _alone_, you wouldn't know. I understand that this is more of a theoretical problem then a practical problem but it still holds (in my opinion).

[tptacek]

The subtlety missed in these conversations is that almost all the information there is for typical error handling --- that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors.

(Rust then improves drastically on the situation with pattern matching, which would simply improve Go with no tradeoffs I can really discern, just so we're clear that I'm not saying Go's error story is at parity with Go. But I'd also point out that Rust error handling at a type level is kind of a painful mess as well.)

[benrazdev]

>that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors.

it's only present when you downcast though?

[tptacek]

It's not super ergonomic, but the information is there, in about the same density as it would be in a Rust app, supporting the same error handling strategies (ie, discriminating between transient and durable errors, &c).

[lokar]

I feel that in general, in the past 20+ odd years there has been an over emphasis on complex control flow with errors.

Lots of different fine grained error types with complex logic spread out over several call layers.

ime it’s better to aim for simpler handling, which seems to match go