July 2, 2024
Sylvain Kerkour writes:
Rust adoption is stagnating not because it’s missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day.
… no company outside of AWS is making SDKs for Rust … it has no official HTTP library.
As a result of Rust’s lack of official packages, even its core infrastructure components need to import hundreds of third-party crates.
cargo imports over 400 crates.
crates.io has over 500 transitive dependencies.
…the offical libsignal (from the Signal messaging app) uses 500 third-party packages.
… what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn’t even match the content of their Git repository.
…how I would do it (there may be better ways):
A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. … to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.
[stdx packages to include, among others]:
gzip, hex, http, json, net, rand
Read Rust has a HUGE supply chain security problem
Submitter’s note:
I find the author’s writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.
Rust adoption is stagnating
Is it? I would like to see some evidence for that.
because of [the small standard library and potentially supply chain security issues]
Yeah I can guarantee that is not a significant reason for people to avoid Rust. If it was people wouldn’t use NPM, where the problem is even worse.
I do think it would be good to putt some more stuff in the standard library makes sense, or even just add some kind of official sanction of de facto standard library crates like
regex… But this author is an idiot.Rust adoption is stagnating
Is it? I would like to see some evidence for that.
When comparing crates.io statistics
Year Crates Yearly Crates Increase Downloads Yearly Downloads Increase 2018 21,162 - 688,268,999 - 2019 29,757 8,595 1,457,578,834 769,309,835 2020 41,539 11,782 3,079,874,235 1,622,295,401 2021 64,658 23,119 8,235,327,111 5,155,452,876 2022 86,776 22,118 17,546,769,164 9,311,442,053 2023 119,145 32,369 35,556,469,191 18,009,700,027 2024 149,970 30,825 72,083,950,414 36,527,481,223 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.
I am asking for some kind of official badge or something on crates.io. Currently it just looks like any other crate. Dart has a feature like this I believe.
And
regexwas just an example. There are other crates that should be officially sanctioned but aren’t.@FizzyOrange@programming.de It’s shown in the “owners”.
Regarding the crates that should be “officially sanctionned”, what would this mean besides a fancy badge?
It would mean a fancy badge, ideally being listed in the official docs, and probably some kind of promise about maintaining it.
It’s shown in the “owners”.
This is just way too subtle IMO.
@FizzyOrange the Rust project is not an organisation you have a contract with. The only guarantee of maintenance you get are that of the MIT and Apache licenses.
@FizzyOrange And a lot of crates you would want to see “blessed”, are already in the Rust cookbook: https://rust-lang-nursery.github.io/rust-cookbook/
I clearly didn’t mean a legal contract. Come on.
@FizzyOrange My point is that regardless of whether it’s “blessed” by the Rust project, your only guarantee of maintenance is only that there are developers or other companies motivated to maintain the project. That also applies to individual parts of the standard library.
Just like with the non-blessed versions, you need to pay attention to who actually maintains it, and guess whether this crate or feature will be maintained in the long run.
It is true that having many dependencies is supply chain attack. However, this is the result of combining the following:
- The UNIX mantra of “do one thing, and do it well”
- The more things a program does, the more intuitive and useful it is.
If you want to keep the 2, you’re gonna need a lot of dependencies. To significantly decrease the amount of dependencies you’re gonna need to drop one of those, there’s no other way around it.
If you wanna know what happens when you drop the UNIX mantra look at any discussion about systemd.
If you drop the second one, everybody would have to bring their own glue. Making computers only accessible to Linux gurus that master the “|” operator and study CLI program arguments in their spare time.
I don’t know why this article focuses on rust specifically. Every language has this problem. And cargo itself has many ways to mitigate this.
- Lockfiles & caches: prevents unwanted version updates.
- Custom registries: You don’t have to use crates.io, that’s just the default. Set up your own registry with only whitelisted crates.
- Use GitHub instead of a registry: cargo has great support for this. If you want your dependencies to always match their GitHub repos, just download from GitHub and compile your own.
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.
