[thinkharderdev]

I don't understand what you would include in the std lib exactly. Defining error types is just defining regular types with domain-specific error information. Macros to make that less verbose seems like the exact sort of thing you would want to be implemented in third-party libraries.

[tensor]

Except as a newcomer to the language, I didn't know about anyhow or thiserror and spent an immense amount of time figuring out how to solve this problem, and writing all the boilerplate. This is not pragmatic and not ok.

I would say a language like Go is well designed in that it has an overall design philosophy and you can see that throughout the language, including in the limitations which are often intentionally chosen. One part of their philosophy that I really appreciate is their intention to make the language pragmatic in industry settings, and making typical things obvious to newcomers is a huge part of that.

Even if your solution is macros (which may be ok, but can also make the underlying generated code more opaque), it should be part of the standard library and part of the language manual. Making things the "officially approved way of handling a problem" has benefits beyond newcomers too, it gives the entire language more consistency resulting in a far more cohesive design.

[thinkharderdev]

"The" solution is not macros. The solution is what is provided by the language. If you are calling a bunch of different functions that return different error types then you either have to map them manually (using map_err) or you can create your own error type and implement From<XYZError> to automatically lift into your own error type. I agree that it is a lot of boilerplate which is why there are good libraries for generating the boilerplate with macros. But the underlying mechanism is not really obscure. It is covered quite well in the rust book (https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...).