[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).