5 ms·

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16 https://github.com/doy/rbw/blob/main/Cargo.toml#L16 You're still pulling a lot of dependencies. At l

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16 https://github.com/doy/rbw/blob/main/Cargo.toml#L16 You're still pulling a lot of dependencies. At least they're pinned though.

mayama 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.
  - 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 6mo 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 6mo ago
    Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!
  - saghm 6mo 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 6mo 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.
vablings 6mo ago
Wait, you're telling me that node deps are not pin by default. Every time you run your code you might be pulling in a new version. No wonder...
- hombre_fatal 6mo ago
  Node deps are pinned: https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-j... The problem is that you also want to update deps.
  - bfivyvysj 6mo ago
    Why?
    - NetMageSCW 5mo ago
      Because they could have a security flaw that might compromise your project or any users of it.
      - vablings 5mo ago
        For any of my rust projects I really don't bump my deps unless dependabot shows a serious vulnerability or I want to use a new feature added. Outside of that my deps are locked to the last known good version i use.
saghm 6mo ago
> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.
- subarctic 6mo ago
  Is there a plan to change this? I don't see why --locked shouldn't be the default
  - wycats 6mo ago
    As one of the original authors of Cargo, I agree. lockfiles are for apps and CLIs are apps. QED.
    - saghm 6mo ago
      Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.0 years of Rust, whereas at this point I think it's more common for me to see than not. Do you think it's an actively bad practice, completely benign, or something in between where it makes sense in some cases but probably should still be avoided in others? Offhand, the only variable I can think of that might influence a different choice is that maybe closed-source packages been reused within a company (especially if trying to interface with other package management systems, which I saw firsthand when working at AWS but I'm guessing is something other large companies would also run into), but I'm curious if there are other names nuances I haven't thought of

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16 https://github.com/doy/rbw/blob/main/Cargo.toml#L16 You're still pulling a lot of dependencies. At least they're pinned though.

mayama 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.
- 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 6mo 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 6mo ago
  Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!
- saghm 6mo 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 6mo 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.

vablings 6mo ago

Wait, you're telling me that node deps are not pin by default. Every time you run your code you might be pulling in a new version. No wonder...

hombre_fatal 6mo ago
Node deps are pinned: https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-j... The problem is that you also want to update deps.
- bfivyvysj 6mo ago
  Why?
  - NetMageSCW 5mo ago
    Because they could have a security flaw that might compromise your project or any users of it.
    - vablings 5mo ago
      For any of my rust projects I really don't bump my deps unless dependabot shows a serious vulnerability or I want to use a new feature added. Outside of that my deps are locked to the last known good version i use.

saghm 6mo ago

> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.

subarctic 6mo ago
Is there a plan to change this? I don't see why --locked shouldn't be the default
- wycats 6mo ago
  As one of the original authors of Cargo, I agree. lockfiles are for apps and CLIs are apps. QED.
  - saghm 6mo ago
    Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.0 years of Rust, whereas at this point I think it's more common for me to see than not. Do you think it's an actively bad practice, completely benign, or something in between where it makes sense in some cases but probably should still be avoided in others? Offhand, the only variable I can think of that might influence a different choice is that maybe closed-source packages been reused within a company (especially if trying to interface with other package management systems, which I saw firsthand when working at AWS but I'm guessing is something other large companies would also run into), but I'm curious if there are other names nuances I haven't thought of