To simplify even more, you don't actually need `Display` or `Error` impls. I use Error enums frequently without display or Error impls. Though, with better backtrace support coming it'll be handy to have Error and the Backtrace related APIs implemented.
(Sidenote, I don't use `impl Error` because I never use `Box<dyn Error>`. Which isn't to say that's correct, just to say that I've never had the need to implement it)
Even though GP meant to highlight compiler error messages, I also have to take my hat off for the library/application error-handling story in Rust.
Using a crate such as thiserror[1] combined with displaydoc[2] makes handling errors in a structured manner a great experience. I love how the error handling story has evolved over the last couple of years in Rust, and it really feels like we're entering into the final stretch of fine-tuning to get the best possible experience.
And yes, anyhow[3] is also great, it serves a different purpose, but I frequently reach for all three crates.
Anyhow isn't really about error handling, but about error reporting. With an ordinary enum error, I can match and easily handle the error if I want to handle some errors in special ways. If I want to handle an anyhow error, I have to do string matching on the message, or try to downcast it, which is cumbersome.
What anyhow makes easier is to collect many types of errors together and reporting the errors to the user.
Just a note, I agree with both of you :)