The following articles may also be of interest to the audience:

- The definitive guide to error handling in Rust [0]

- Error Handling for Large Rust Projects - Best Practice in GreptimeDB [1]

- Designing error types in Rust [2]

- Modular Errors in Rust [3]

[0]: https://www.howtocodeit.com/articles/the-definitive-guide-to... [1]: https://greptime.com/blogs/2024-05-07-error-rust [2]: https://mmapped.blog/posts/12-rust-error-handling [3]: https://sabrinajewson.org/blog/errors

I remember people being so excited to use error values instead of exceptions in mainstream languages. But this libraries plus error values combo looks even more complex to me.

Idk, I'd take

   if err != nil {
      return nil, err
   }

More on how best practices in Rust are not documented anywhere but in a bunch of unfindable blog posts. :(

And even then, there's no guarantee what you find is not outdated.

And we slowly circle back to what Rust should have done all along: exceptions with Java/Python-style causal chaining.

I wonder how loudly "the community" would scream at me if I published something that just used panics for all error reporting.

> The core issue is that Rust still hasn't stabilized backtrace propagation on errors.

I would actually strengthen this to: «The core issue with Rust is that Rust still hasn’t stabilized _»