4 ms·

Rust Dependencies Scare Me

25 points by vsgherzi 1y ago

deleted 1y ago
[deleted]
turtleyacht 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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.
  - steveklabnik 1y ago
    You may appreciate this RFC that was just opened https://github.com/rust-lang/rfcs/pull/3810 https://github.com/rust-lang/rfcs/pull/3810
    - vsgherzi 1y ago
      Hi Steve! Big fan! Folks on Bluesky just pointed me in the same direction. Looks like it has potential.
      - steveklabnik 1y ago
        Thanks :) I’m not as positive on it, but at least if you are, you know where to lodge support.
  - rc00 1y 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? 1. https://deadmoney.gg/news/articles/migrating-away-from-rust https://deadmoney.gg/news/articles/migrating-away-from-rust
weird_trousers 1y ago
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.
- vsgherzi 1y 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 1y 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 1y 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!).

25 points by vsgherzi 1y ago

deleted 1y ago

[deleted]

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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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.
- steveklabnik 1y ago
  You may appreciate this RFC that was just opened https://github.com/rust-lang/rfcs/pull/3810 https://github.com/rust-lang/rfcs/pull/3810
  - vsgherzi 1y ago
    Hi Steve! Big fan! Folks on Bluesky just pointed me in the same direction. Looks like it has potential.
    - steveklabnik 1y ago
      Thanks :) I’m not as positive on it, but at least if you are, you know where to lodge support.
- rc00 1y 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? 1. https://deadmoney.gg/news/articles/migrating-away-from-rust https://deadmoney.gg/news/articles/migrating-away-from-rust

weird_trousers 1y ago

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.

vsgherzi 1y 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 1y 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 1y 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!).