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)
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.
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.
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.
Noted. And you are right about not giving examples. That was a mistake and bear in mind I wrote a rant which I didn't expect to get exposure. A buddy thought it was good enough to submit and that's how I'm here. No is more surprised than I that this showed up here.
In terms of specific examples, I'm now running:
* Starship.rs -- prompt management for my terminal. This is something I've always had issues with and Starship does a great job, better than I've ever had before.
* NuShell which I run experimentally on my alternate box and I think I'm finally ready to use in production.
* Warp.dev which I'm currently shutting down iTerm2 windows to shift over.
* Zed -- which I just got late today and I'm going *try* and use this week. I have less time with this but looks quite good.
I’ve been dealing with an example of just what you described: Unicode normalization and collation. There’s a good normalization library in Rust—in terms of the quality of the code, standards conformance, how comfortable I am depending on it, etc.—but it’s a full order of magnitude slower than icu4c.[0] Which shouldn’t come as a surprise! Some of these things take decades.
Recently, I looked at some string functions in the Rust stdlib and noticed it is full of unsafe code. With comments like "this writes ascii only, so we do not utf-8 validation"
Interesting. That actually doesn't surprise me. I'm pretty new to the ecosystem and still at the fanboy stage. Learning anything new is hard. Learning something new that is KNOWN TO BE HARD is likely going to be harder. And since the way you make software is by building stuff, and we now do that in the open, we are likely to see some crap (think digital poop droppings littering an ecosystem).
Interesting thoughts on the backend web dev front. Not surprising at all because a compiled language is a poor match for the problem space (web dev is basically string manipulation -- which I don't really think fits Rust).
The rust project itself really is superb. Steve K is doing great work.
I just started looking at `vulkano` this week and have found it pleasant to work with so far. Do you have examples of high level graphics libraries that you consider poor quality?
Yeah I could see that. It seems nice and simple at a glance, but I remember some of the lifetime requirements being incredibly strict and hard to work with
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)