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.

tialaramex 4 days ago | parent | next [-]

I'm not sure how this idea makes coherent sense. Best practices are going to be determined by users, so even in a language where there's a BDFL or some ludicrous committee flying to Hawaii to discuss everything in person a central "Best practice" document is not actually best practices it's just somebody's opinion but with a rubber stamp.

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.

	▲	tayo42 4 days ago \| parent \| next [-]
		Something like pep8 is useful. 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.
	▲	m11a 4 days ago \| parent \| prev [-]
		Think you need a healthy mix? 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.

▲

m11a 4 days ago | parent | prev | next [-]

For Rust, there are a few blogs that lean more on fundamentals and language design (like https://without.boats/blog, https://smallcultfollowing.com/babysteps).

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

▲

csomar 4 days ago | parent | prev | next [-]

Rust has the Error type. Libraries are add-ons and not part of the language.

	▲	tialaramex 4 days ago \| parent [-]
		Well, Rust's standard library provides two types named Error, their full names are core::fmt::Error (aka std::fmt::Error) and std::io::Error 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.

▲

imtringued 4 days ago | parent | prev [-]

This has very little to do with Rust.

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.

	▲	baq 4 days ago \| parent [-]
		They are not first by any means, but the popular languages definitely focus on the happy path with varying but consistently insufficient degrees of enforcement of handling deviations… because that’s easy to iterate on. 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.