My experience with Rust codebases has been different from the Author's. I think his or her points about why Rust should encourage high quality programs makes sense. In practice, most of the Rust OSS I find is poor quality, ie the article's lament of "today's software quality crisis – crashes, bloat and more." I'm suspicious my observations are because I'm viewing select slice of Rust code; perhaps the higher quality code examples aren't OSS, so I haven't seen them.

Examples:

- Rust is well-suited to Embedded. There are a handful of high-quality tools (eg probe-run, defmt, SVD2Rust etc). Most of the higher level libraries, and the chat on Rust embedded communication channels are a mess. Dependency hell, poor APIs, hardware support that's been designed to make trivial examples and never tested on practical firmware etc.

- Backend web dev - Several Flask analogs, but nothing that makes sense to use for a web page. Internally, dependency hell, and filled with generics and Async.

- Graphics programming - Churn, and low-quality results compared to C libraries eg for Vulkan. Fine if you use the libraries that are thin wrappers on the C APIs, but ones that try to apply a Safe or Rusty API are lower quality.

I don't mean this as a disagreement to the article - Rust gives developers tools to make high quality software! The Rust project itself is superb. I'm surprised that his predictions don't match with what we have. (yet)

nightski

In both cases I think the problem is that you and the author are slinging around judgements without any actual references to specific code. It's easy to make broad statements.

In your case, you tend to imply that these are due to Rust itself. But is it just due to manpower? C APIs have had so many man hours behind them I can't imagine Rust even being within orders of magnitude.

Without diving into the details these broad statements are just pointless.

the__alchemist

I don't think the poor quality code is due to Rust itself. I think manpower is a big part of it. Rust doesn't inherently lead to good quality code, which the article implies.

Re code examples - Here's the Rust Awesome Embedded List - a collection of tools (especially hardware support drivesr) - https://github.com/rust-embedded/awesome-embedded-rust

Most of them aren't suitable for use in practical projects; they're missing important features like non-blocking operation, low-power modes, DMA etc - these are all things that will come up in embedded projects, but aren't needed for the "hello world" examples they include. Part of this is from attempting to conform to embedded-HAL traits, which support only the broadest feature sets.