Rust

Rust adoption is stagnating

Is it? I would like to see some evidence for that.

When comparing crates.io statistics

By downloads, 2023-2024 has been Rust’s best year so far.

@FizzyOrange @ericjmorey The Regex crate is already part of the rust-lang organisation on GitHub. I don't know what you are asking for.

Part of this is because the article’s author pushes a lot of sensationalist content to drive traffic to their Rust book(s). I remember similar articles several times over the last year, at least one of which was a thinly disguised ad for the Black Hat Rust book. That doesn’t mean the author is wrong, necessarily, but it does get annoying after a bit.

making points that aren’t even particularly that new.

(putting my Rust historian hat on)

Even the name stdx[1][2] is not original.

It was one of multiple attempts to officially or semi-officially present a curated a list of crates. Thankfully, all these attempts failed, as the larger community pushed against them, and more relevantly, as the swarm refused to circle around any of them.

This reminds of a little-known and long-forgotten demo tool named cargo-esr[1][2]. But it's not the tool, but the events it was supposedly created as a response to that is worth a historical mention, namely these blog posts[1][2], and the commotion that followed them[1][2][3][4].

For those who were not around back then, there was an obscure crate named mio, created by an obscure developer named Carl Lerche, that was like the libevent/libuv equivalent for Rust. mio was so obscure I actually knew it existed before Rust even hit v1.0. Carl continued to do more obscure things like tokio, whatever that is.

So, the argument was that there was absolutely no way whatsoever that one could figure out they needed to depend on mio for a good event loop interface. It was totally an insurmountable task!

That was the circus, and "no clown left behind" was the mindset, that gave birth to all these std-extending attempts.

So, let's fast forward a bit. NTPsec didn't actually get (re)written in go, and ended up being a trimming, hardening, and improving job on the original C impl. The security improvements were a huge success! Just the odd vulnerability here and there. You know, stuff like NULL dereferences, buffer over-reads, out-of-bounds writes, the kind of semantic errors Rust famously doesn't protect from 🙂

To be fair, I'm not aware of any big NTP implementations written in Rust popping up around that time either. But we do finally have the now-funded ntpd-rs effort progressing nicely.

And on the crates objective metrics front, kornel of lib.rs fame, started and continues to collect A LOT of them for his service. Although, he and lib.rs are self-admittedly NOT opinion-free.

DISCLAIMER: I didn't even visit OP's link.

Developers should think about what libraries they trust, but it seems that most of the time they'll choose whatever is most convenient for handling the immediate problems they're working to solve.

Anytime anyone mentions integrating an HTTP client into Rust's std, all it takes is one good Python anecdote to shut that discussion right down.

Having the standard library be stable and not try to add a bunch of support for changing standards is a long-term benefit to the language. Having "de-facto standard libs" with crates like url, http, etc ends up being better because they can evolve independently from the standard library, at the pace their respective domains evolve.

Although, I suppose an argument could be made that url is unlikely to really evolve anymore.

Java and Python projects can be based almost entirely on the standard library because there's so much in there (or packages with minimal/no third party dependencies).

C++ it's not uncommon for the entire code base or the majority of the code base to be internal (and maybe make use of the standard library or a library under the boost umbrella).

The "every language" is largely a "languages that became popular in the NodeJS era" issue.

I've read that. Defining a supplier as someone with whom you have a direct business relationship with seems intentionally narrow in an unhelpful way that just further muddies the waters around the issue at hand. Making something generally available to others means that you're supplying others with that thing. While it's true that you may have no further obligations to those that receive your software, the person receiving the software needs to evaluate their risks around using and depending on that software regardless of the existence of a business relationship with the supplier. Hence supply chain risk evaluation is always necessary. That risk evaluation, or lack thereof, can result in a security problem. These problems can propagate widely within a software ecosystem. This is true with and without the existence of direct business relationships between suppliers and recipients of software.

The whole article can be summarized by saying if you want support services related to the software written by others, negotiate a support agreement related to that software. That has nothing to do with taking a wide or narrow interpretation of the word supplier.

I have a better idea that can solve everyone's problems. Businessnes make their own libraries and keep it closed for themselves. The FOSS community will use it for FOSS stuff. I'm more of a libre person that.