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 even then, there's no guarantee what you find is not outdated.
A central dogma approach just means you need more doublethink, the "best practices" still gradually change but now you're pretending they've always been this way even as they shift beneath your feet.
I get what poster means.
Everytime I come back to rust I find it hard to know what the latest thing and way to do something is.
eg: if you want distributed systems, esp Java-style, https://www.martinfowler.com is a pretty handy reference. (similar for other areas of SWE).
It’s nice to have a single resource that documents a bunch of non-obvious but still-generally-accepted engineering practices relevant to a domain. It’s of course an opinion, but is reasonably uncontroversial. Or at least, you won’t go too wrong while you develop your own taste in said domain.
For misc Rust engineering, like the OP, I agree it’s quite scattered. I personally like to save good ones in my Feedbin as I encounter them
But, neither of these is intended as "the" error type - unless you're a formatter or an I/O abstraction they're not the error types you want.
Rust provides a trait core::error::Error (aka std::error::Error) and that might be what you're thinking about. It's recommended that your own private error type or types should implement this trait but nothing requires this in most contexts.
The entire software development industry has slept on error handling without exceptions and Rust developers are the first ones to actually start addressing the problems.
This problem should have been solved decades ago by C/C++ developers.
Java e.g. would benefit from a strict null mode, but the legions of half baked ‘engineers’ wouldn’t comprehend how to write software when you can’t initialize a reference to null and only set it later.