That's the main criticism my colleagues have about Rust: a lot of unmaintained crates, and most of the time a lot of dependencies for... (almost) nothing.
It seems most of Rust developers adopt the pov of web front-end developers since a few years: depend on a lot of libraries for small things, never update your project to 1.0, and abandon "quickly" to build something new... and redo it again.
I really hope that alternatives like Zig or Jai will not let the community do like what they did with Rust.
stefanos82 · 14h ago
I thought I was alone thinking like this.
Honestly, when I want to compile a Rust project and see all these dependencies getting pulled in to get compiled along with the project, it gives me goosebumps, because I don't know whether these crates are safe and secured or not...
weird_trousers · 12h ago
You're definitely not alone.
This situation is not new, and it isn't acceptable either.
The concept of `features` when using a crate is kinda cool as "you only download / compile what you use" *but* most of the crates are very badly designed, and also developers do not tend to reinvent a very tiny wheel when they can, but heavily depend of possibly dangerous crates to just serialize or deserialize a very simple data structure...
It's very annoying, as this increases the compilation time and introduces possible unsafe behavior in larger crates.
vsgherzi · 14h ago
Yeah, I think in some sense it definitely looks worse than it is since a single crate like Tokio is spread among 20-30 crates. However even accounting for that there's still just alot of raw code...
vsgherzi · 14h ago
It's such a cool language, maybe there's a way out or something I'm not seeing? Cloudflare, discord, and oxide seem to make it work pretty well... Always excited to see what new languages do. However it does seem like industry already has significant investment in rust so it seems like something we'll have to solve sooner than later....
steveklabnik · 12h ago
It’s pretty simple: you choose the dependencies you want to have. Don’t like having a ton of them? Either choose carefully (which you should already be doing), or write it yourself.
Most people prefer to build off of the work of others, rather than reinvent the world for every project. That trade off is a trade off though, and nothing prevents you from taking the other side of it.
vsgherzi · 11h ago
I get that. In general for something like a production server in cpp versus rust do you think the rust version is going to just have more lines of code associated with it or is it just the way I'm thinking about it? I love the Oxide podcast where you guys talk about your favorite crates and some of the ones you guys use in production. Are the dependencies something you guys really stress and investigate before pulling one in? I know things like axum are replaced with dropshot since you guys deemed it critical to your business (super cool crate!).
steveklabnik · 10h ago
You just can’t draw connections between number of dependencies, numbers of lines of code, and code you actually use, across ecosystems. See https://wiki.alopex.li/LetsBeRealAboutDependencies as an example of getting into the details about Rust vs C in this regard.
We don’t hyper stress about it. We do take care, in some projects (like embedded ones) we need to care a lot about binary size and so pay very close attention, and we keep abreast of security issues, etc.
Dropshot wasn’t written because it was critical to the business, it was because nothing had the OpenAPI support at the time we write it. It Axum or something else did, we’d have used it. We only write our own stuff when things in the ecosystem aren’t fit for purpose. We do sometimes find that our needs are different than others and so write our own, but this isn’t borne out of concern for dependency count.
vsgherzi · 10h ago
Thank for the reply! I see, I guess I have alot more to think about ...
turtleyacht · 14h ago
Probably hard to do during nine-to-five, but personally commit to being a contributor on every dependency used.
Like having mini contracts with every package, even if it's just to reproduce bugs, maintain a personal test suite, or to steer newcomers to resources.
Otherwise, we will always be in the dark about our dependencies, building our flying castles. (They float, but where's the foundation?)
Alternatively, there are open-source code scanners and bill-of-material security tools. Those could be added as triggered workflows in your projects, to run on each pull request.
As well, the author did rewrite dotenv's core features to replace it.
vsgherzi · 14h ago
Yeah that's not a bad suggestion, I should def be more involved in the ecosystem. To do that for every crates seems exhausting though... Any favorite suggestions for scanners or SBOM creation tools?
turtleyacht · 14h ago
Snyk has a free tier, but their Github integration passes workflows green more often than not. If you run it yourself as a container, you get finer-grained control over what to do with error code 1 versus error code 2: a vulnerability in changed versions, versus a pipeline error.
Sonar is free for open-source projects, but less package version security and more "use --ignore-scripts in npm," "don't be root in Docker container," and such.
vsgherzi · 14h ago
Noted, I'll check it out! A shame so many are bound to github most of my workflow is tied to git on secured servers
armchairhacker · 14h ago
IME unmaintained Rust packages usually aren't an issue, because Rust's backwards-compatibility is really good. Only if there's an unidiomatic design or bug in the part that you use, or a security vulnerability.
Rust dependency bloat may be an issue, but with good static analysis maybe not (the compiler can effectively remove dead code unlike JavaScript, and the IDE may be able to effectively filter it).
vsgherzi · 14h ago
I wonder if there's a way to do a pass on a repo to remove code that will never be used due to the hardware you're targeting. You do have a good point in that it being unmaintained isn't necessarily the end of the world, I just kinda start to sweat when I think about ZX and see the advisories.
rc00 · 14h ago
> Many call for adding more to the rust standard library much like Go
> So now I pose the question to you what do we do?
1. Port your application to the language/tool that fits your needs like Go.
2. Hope that a language like Zig decides to feature a standard library as good as Go.
vsgherzi · 14h ago
It feels a bit like throwing the baby out with the bathwater to completely swap languages. I was hoping rust could be a more general language for me.... I know they're not interested but I wonder if the foundation would ever entertain an opt in more expansive std library?
Go's is very nice however if I remember they ran into an issue with crypto that was hard to fix due to it being so bundled to the std library.
It seems most of Rust developers adopt the pov of web front-end developers since a few years: depend on a lot of libraries for small things, never update your project to 1.0, and abandon "quickly" to build something new... and redo it again.
I really hope that alternatives like Zig or Jai will not let the community do like what they did with Rust.
Honestly, when I want to compile a Rust project and see all these dependencies getting pulled in to get compiled along with the project, it gives me goosebumps, because I don't know whether these crates are safe and secured or not...
The concept of `features` when using a crate is kinda cool as "you only download / compile what you use" *but* most of the crates are very badly designed, and also developers do not tend to reinvent a very tiny wheel when they can, but heavily depend of possibly dangerous crates to just serialize or deserialize a very simple data structure...
It's very annoying, as this increases the compilation time and introduces possible unsafe behavior in larger crates.
Most people prefer to build off of the work of others, rather than reinvent the world for every project. That trade off is a trade off though, and nothing prevents you from taking the other side of it.
We don’t hyper stress about it. We do take care, in some projects (like embedded ones) we need to care a lot about binary size and so pay very close attention, and we keep abreast of security issues, etc.
Dropshot wasn’t written because it was critical to the business, it was because nothing had the OpenAPI support at the time we write it. It Axum or something else did, we’d have used it. We only write our own stuff when things in the ecosystem aren’t fit for purpose. We do sometimes find that our needs are different than others and so write our own, but this isn’t borne out of concern for dependency count.
Like having mini contracts with every package, even if it's just to reproduce bugs, maintain a personal test suite, or to steer newcomers to resources.
Otherwise, we will always be in the dark about our dependencies, building our flying castles. (They float, but where's the foundation?)
Alternatively, there are open-source code scanners and bill-of-material security tools. Those could be added as triggered workflows in your projects, to run on each pull request.
As well, the author did rewrite dotenv's core features to replace it.
Sonar is free for open-source projects, but less package version security and more "use --ignore-scripts in npm," "don't be root in Docker container," and such.
Rust dependency bloat may be an issue, but with good static analysis maybe not (the compiler can effectively remove dead code unlike JavaScript, and the IDE may be able to effectively filter it).
> So now I pose the question to you what do we do?
1. Port your application to the language/tool that fits your needs like Go.
2. Hope that a language like Zig decides to feature a standard library as good as Go.
Go's is very nice however if I remember they ran into an issue with crypto that was hard to fix due to it being so bundled to the std library.
Folks on Bluesky just pointed me in the same direction. Looks like it has potential.
I’m not as positive on it, but at least if you are, you know where to lodge support.