5 ms·

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others. https://lib.rs/

by mayama 5mo ago

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others. https://lib.rs/crates/rbw https://lib.rs/crates/rbw

embedding-shape 5mo ago
326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. Takes what, maybe 15 seconds to compile on a high-core machine from scratch? Isn't the end of the world. Worse is the scope to have to review all those things, if you'd like to use it for your main passwords, that'd be my biggest worry. Luckily most are well established already as far as I can tell.
- elAhmo 5mo ago
  "326 seems large, but not abnormal" was the state of JS in the past as well. Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.
  - seanw444 5mo ago
    It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.
    - embedding-shape 5mo ago
      That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.
      - seanw444 5mo ago
        That's true. But it does seem like a logic result of having no real standard library. That lone fact has kept me away from Rust for real projects, because I don't want to pull in a bunch of defacto-standard-but-not-officially dependencies for simple tasks. That's probably a large contributor to the current state of dependency bloat.
        embedding-shape 5mo ago
        Yeah, it does require you to be meticulous about what you depend on. Personally I stick with libraries that don't use 100s of other crates, and tried and reviewed various libraries over the year, so you have your "toolkit" of libraries you know are well built and you know how they work internally. Ultimately in any language you get the sort of experience you build for yourself with the environment you setup, it is possible in most languages to be more conservative and minimal even if the ecosystem at large is not, but it does require more care and time.
        wongarsu 5mo ago
        'no real standard library' doesn't seem entirely fair. Rust has a huge standard library. What it does have is the policy to only include "mature" things with little expected API evolution in the standard libary, which leaves gaping holes where a json parser, a http client or a logging library should be. Those are all those defacto-standard-but-not-officially dependencies
        NetMageSCW 5mo ago
        Perhaps that’s just a sign Rust isn’t suitable for those type of projects.
        pdimitar 5mo ago
        It's a sign that they learned from Python more than anything else. Better be conservative than have Python's situation of multiple versions of those common functionalities (in the stdlib) that almost nobody uses and goes for 3rd party libraries anyway. Is that a better state of affairs? The Rust vs. Node comparison seems very shallow to me, and it seems to require a lot of eye squinting to work. People have beef with Rust in other, more emotional ways, and welcome the opportunity to pretend they dislike it on seemingly-rational grounds a la "Node bad amirite lol".
    - cromka 5mo ago
      Same here.
    - atdt 5mo ago
      What exactly would you have done differently? Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.
      - Ferret7446 5mo ago
        Yet Go is half a decade older and seems to have handled the situation much better.
        pdimitar 5mo ago
        How does it handle better, exactly?
        mayama 5mo ago
        You can write simple http server or rest client with stdlib in Go. No need to include tokio, serde and hundred other cargos which constantly break things. I have apps written in Go more than a decade ago work the same now with recent version of Go. Where as, I had issues with getting few year old github apps in rust compiling and working in rust.
        pdimitar 5mo ago
        I know what you mean about Go vs. Rust here and I've seen it firsthand, though I believe the effect is overblown. I was able to modernize a fairly old project in literal 15 minutes by using Cargo Clippy's fix mode + a few small hand-crafted changes. To me a rich stdlib is not a selling point. Both ecosystems have a ton of very high-quality libraries.
    - jeroenhd 5mo ago
      I doubt Microsoft's kernel/system Rust code is pulling in a lot of crates. The Linux kernel sure isn't, and Android's Bluetooth stack doesn't seem to either. Using crates is a choice. You can write fully independent C++ or you can pull in Boost + Qt + whatever libraries you need. Even for C programs, I find my package manager downloading tons of dependencies for some programs, including things like full XML parsers to support a feature I never plan to use. Javascript was one of the first languages to highlight this problem with things like left-pad, but the xz backdoor showed that it's also perfectly possible to do the same attack on highly-audited programs written in a system language that doesn't even have a package manager.
- dijit 5mo ago
  Why are you talking about compile times in a thread about supply chain security. 326 packages is approximately 326 more packages than I will ever fully audit to a point where my employer would be comfortable with me making that decision (I do it because many eyes make bugs shallow). It's also approximately 300 more than the community will audit, because it will only be "the big ones" that get audited, like serde and tokio. I don't see people rushing to audit `zmij` (v1.0.19), despite it having just as much potential to backdoor my systems as tokio does.
- Ferret7446 5mo ago
  > 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. That's a damning indictment of Rust. Something as big as Chrome has IIRC a few thousand dependencies. If a simple password manager CLI has hundreds, something has gone wrong. I'd expect only a few dozen
- gtest 5mo ago
  > 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. How many are third-party?
xvedejas 5mo ago
Does this take into account feature flags when summing LOC? It's common practice in Rust to really only use a subset of a dependency, controlled by compile-time flags.
- gsnedders 5mo ago
  Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!
- saghm 5mo ago
  My experience has been that while there's significant granularity in terms of features, in practice very few people actively go out of their way to prune the default set because the ergonomics are kind of terrible, and whether or not the default feature set is practically empty or pulls in tons of stuff varies considerably. I felt strongly enough about this that I wrote up my only blog post on this a bit over a year ago, and I think most of it still applies: https://saghm.com/cargo-features-rust-compile-times/ https://saghm.com/cargo-features-rust-compile-times/
traderj0e 5mo ago
For a given tool, I'd expect the Rust version to have even more deps than the JS version because code reuse is more important in a lower-level language. I get the argument that JS users are on average less competent than Rust users, but we're talking about authors who build serious tools/libs in the first place.

by mayama 5mo ago

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others. https://lib.rs/crates/rbw https://lib.rs/crates/rbw

embedding-shape 5mo ago

326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. Takes what, maybe 15 seconds to compile on a high-core machine from scratch? Isn't the end of the world. Worse is the scope to have to review all those things, if you'd like to use it for your main passwords, that'd be my biggest worry. Luckily most are well established already as far as I can tell.

elAhmo 5mo ago
"326 seems large, but not abnormal" was the state of JS in the past as well. Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.
- seanw444 5mo ago
  It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.
  - embedding-shape 5mo ago
    That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.
    - seanw444 5mo ago
      That's true. But it does seem like a logic result of having no real standard library. That lone fact has kept me away from Rust for real projects, because I don't want to pull in a bunch of defacto-standard-but-not-officially dependencies for simple tasks. That's probably a large contributor to the current state of dependency bloat.
      - embedding-shape 5mo ago
        Yeah, it does require you to be meticulous about what you depend on. Personally I stick with libraries that don't use 100s of other crates, and tried and reviewed various libraries over the year, so you have your "toolkit" of libraries you know are well built and you know how they work internally. Ultimately in any language you get the sort of experience you build for yourself with the environment you setup, it is possible in most languages to be more conservative and minimal even if the ecosystem at large is not, but it does require more care and time.
      - wongarsu 5mo ago
        'no real standard library' doesn't seem entirely fair. Rust has a huge standard library. What it does have is the policy to only include "mature" things with little expected API evolution in the standard libary, which leaves gaping holes where a json parser, a http client or a logging library should be. Those are all those defacto-standard-but-not-officially dependencies
        NetMageSCW 5mo ago
        Perhaps that’s just a sign Rust isn’t suitable for those type of projects.
        pdimitar 5mo ago
        It's a sign that they learned from Python more than anything else. Better be conservative than have Python's situation of multiple versions of those common functionalities (in the stdlib) that almost nobody uses and goes for 3rd party libraries anyway. Is that a better state of affairs? The Rust vs. Node comparison seems very shallow to me, and it seems to require a lot of eye squinting to work. People have beef with Rust in other, more emotional ways, and welcome the opportunity to pretend they dislike it on seemingly-rational grounds a la "Node bad amirite lol".
  - cromka 5mo ago
    Same here.
  - atdt 5mo ago
    What exactly would you have done differently? Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.
    - Ferret7446 5mo ago
      Yet Go is half a decade older and seems to have handled the situation much better.
      - pdimitar 5mo ago
        How does it handle better, exactly?
        mayama 5mo ago
        You can write simple http server or rest client with stdlib in Go. No need to include tokio, serde and hundred other cargos which constantly break things. I have apps written in Go more than a decade ago work the same now with recent version of Go. Where as, I had issues with getting few year old github apps in rust compiling and working in rust.
        pdimitar 5mo ago
        I know what you mean about Go vs. Rust here and I've seen it firsthand, though I believe the effect is overblown. I was able to modernize a fairly old project in literal 15 minutes by using Cargo Clippy's fix mode + a few small hand-crafted changes. To me a rich stdlib is not a selling point. Both ecosystems have a ton of very high-quality libraries.
  - jeroenhd 5mo ago
    I doubt Microsoft's kernel/system Rust code is pulling in a lot of crates. The Linux kernel sure isn't, and Android's Bluetooth stack doesn't seem to either. Using crates is a choice. You can write fully independent C++ or you can pull in Boost + Qt + whatever libraries you need. Even for C programs, I find my package manager downloading tons of dependencies for some programs, including things like full XML parsers to support a feature I never plan to use. Javascript was one of the first languages to highlight this problem with things like left-pad, but the xz backdoor showed that it's also perfectly possible to do the same attack on highly-audited programs written in a system language that doesn't even have a package manager.
dijit 5mo ago
Why are you talking about compile times in a thread about supply chain security. 326 packages is approximately 326 more packages than I will ever fully audit to a point where my employer would be comfortable with me making that decision (I do it because many eyes make bugs shallow). It's also approximately 300 more than the community will audit, because it will only be "the big ones" that get audited, like serde and tokio. I don't see people rushing to audit `zmij` (v1.0.19), despite it having just as much potential to backdoor my systems as tokio does.
Ferret7446 5mo ago
> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. That's a damning indictment of Rust. Something as big as Chrome has IIRC a few thousand dependencies. If a simple password manager CLI has hundreds, something has gone wrong. I'd expect only a few dozen
gtest 5mo ago
> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal. How many are third-party?

xvedejas 5mo ago

Does this take into account feature flags when summing LOC? It's common practice in Rust to really only use a subset of a dependency, controlled by compile-time flags.

gsnedders 5mo ago
Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!
saghm 5mo ago
My experience has been that while there's significant granularity in terms of features, in practice very few people actively go out of their way to prune the default set because the ergonomics are kind of terrible, and whether or not the default feature set is practically empty or pulls in tons of stuff varies considerably. I felt strongly enough about this that I wrote up my only blog post on this a bit over a year ago, and I think most of it still applies: https://saghm.com/cargo-features-rust-compile-times/ https://saghm.com/cargo-features-rust-compile-times/

traderj0e 5mo ago

For a given tool, I'd expect the Rust version to have even more deps than the JS version because code reuse is more important in a lower-level language. I get the argument that JS users are on average less competent than Rust users, but we're talking about authors who build serious tools/libs in the first place.