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 · 59d 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 · 59d 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.
wofo · 58d ago
Some people _do_ care about this (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (culture, I guess?) there isn't much momentum yet to change the status quo.
vsgherzi · 59d 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 · 59d 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 · 59d 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 · 58d 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 · 58d 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 · 58d ago
Thank for the reply! I see, I guess I have alot more to think about ...
antonvs · 58d 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.
Exactly. Why this is even a point of discussion is, to me, an indictment of everyone raising it as an issue.
antonvs · 58d ago
Your “colleagues”?
You’re making the criticism, why not own it?
What you’re saying is the equivalent of Donald Trump’s “many people are saying”. It’s the recourse of the intellectually stunted who can’t muster a convincing argument.
vsgherzi · 58d ago
Because I want my mind to be changed. I see orgs and companies I respect doing things differently than me but I don't understand why. I want to use this language, I want to use this ecosystem so I'm trying to get others who disagree with me to share what they think so I could possibly see things in a different way.
turtleyacht · 59d 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 · 59d 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 · 59d 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 · 59d 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 · 59d 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 · 59d 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 · 59d 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 · 59d 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.
rc00 · 58d ago
You should evaluate on whether it is worth insisting on Rust. Others have gone down that path and it has only ended with regret[1]. The sooner you realize that you don't have the right solution to your problem, the sooner you can start solving it correctly.
What about the crypto library affects how you would use Go to solve your problem?
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.
Exactly. Why this is even a point of discussion is, to me, an indictment of everyone raising it as an issue.
You’re making the criticism, why not own it?
What you’re saying is the equivalent of Donald Trump’s “many people are saying”. It’s the recourse of the intellectually stunted who can’t muster a convincing argument.
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.
What about the crypto library affects how you would use Go to solve your problem?
1. https://deadmoney.gg/news/articles/migrating-away-from-rust
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.