4 ms·

When Rust's ecosystem was booming, the JS/npm way of a myriad small libraries was viewed as superior. I think that there have been dozens of articles pre-left-p

When Rust's ecosystem was booming, the JS/npm way of a myriad small libraries was viewed as superior. I think that there have been dozens of articles pre-left-pad about why it is good and why it's the future. I don't quite blame them, remembering how Python's ecosystem tried to mimic Java back in the day, how PHP tried, consciously or not, to do the same. I'm just wondering what the 2024-2025 dominant fad is going to look like.

steveklabnik 2y ago
Crates.io never had the behavior that led to left-pad, so it didn’t really change any opinions here. Small dependencies are not inherently good. Large dependencies are not inherently bad.
- WesolyKubeczek 2y ago
  Oh just you wait. It doesn't need to be a ragequitting and taking the toys away. If you are accustomed to having long chains of small twisty dependencies, all it takes is one Jia Tan of the Rust world to subtly alter a dependency of a dependency of a high profile dependency to own almost anything written in Rust. The said dependency can even ship precompiled bits of who-knows-which provenance, citing the same excuse as the one the author of serde used.
  - steveklabnik 2y ago
    That is a separate, and valid issue.
    - WesolyKubeczek 2y ago
      All I'm saying that in a maze of twisty little dependencies, all alike, it's very tedious to vet them all, and it's much too easy to end up with thousands of crates for the simplest things. And it's very easy to put nefarious things in once there is a will to do so. It all works well if everyone wants to play nice, but this doesn't scale. I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. I contrast this with Go that has a rich enough standard library so you rarely need a dependency, and you don't need any for mundane stuff, and it makes you think hard about every dependency you introduce. And they got burned early enough so vendoring is a Good Thing now. And then I compare it with Perl, in that on one hand, it has lots of core modules, but then its standard library is lacking in weird places making you reach for CPAN in 100% of the cases writing a non-trivial program (HTTP/TLS comes to mind), and it would be similar to Rust except that CPAN is very slow-paced these days. I'm curious to see how it all evolves.
      - steveklabnik 2y ago
        > it's very tedious to vet them all, It is also very tedious to vet a large dependency, as there's so much code to review. > It all works well if everyone wants to play nice, but this doesn't scale. There are tools like cargo-crev to help scale up the "hey I reviewed the code here and if you trust me, you can trust my review." > I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Yes, on purpose. Rust will try to unify them as much as possible, but if two dependencies rely on incompatible versions, you'll get two. Note that they'll be different types, so if you try and use a foov1 where a foov2 is needed, you'll get a compile error. > Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. This goes both ways: you could also have some code depending on an older, secure version, and a newer one is the one with the vulnerabilty. But also, the way you phrase this makes me think you may misunderstand some details about how this happens: each crate doesn't pin its own version, exactly. The entire dependency graph is looked at holistically. But as I said above, you can still get situations like this, so this is very nitpicky. > And they got burned early enough so vendoring is a Good Thing now. You can absolutely trivially vendor your Rust dependencies as well. It's built into the tooling. > I'm curious to see how it all evolves. Absolutely. Me too.

steveklabnik 2y ago

Crates.io never had the behavior that led to left-pad, so it didn’t really change any opinions here. Small dependencies are not inherently good. Large dependencies are not inherently bad.

WesolyKubeczek 2y ago
Oh just you wait. It doesn't need to be a ragequitting and taking the toys away. If you are accustomed to having long chains of small twisty dependencies, all it takes is one Jia Tan of the Rust world to subtly alter a dependency of a dependency of a high profile dependency to own almost anything written in Rust. The said dependency can even ship precompiled bits of who-knows-which provenance, citing the same excuse as the one the author of serde used.
- steveklabnik 2y ago
  That is a separate, and valid issue.
  - WesolyKubeczek 2y ago
    All I'm saying that in a maze of twisty little dependencies, all alike, it's very tedious to vet them all, and it's much too easy to end up with thousands of crates for the simplest things. And it's very easy to put nefarious things in once there is a will to do so. It all works well if everyone wants to play nice, but this doesn't scale. I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. I contrast this with Go that has a rich enough standard library so you rarely need a dependency, and you don't need any for mundane stuff, and it makes you think hard about every dependency you introduce. And they got burned early enough so vendoring is a Good Thing now. And then I compare it with Perl, in that on one hand, it has lots of core modules, but then its standard library is lacking in weird places making you reach for CPAN in 100% of the cases writing a non-trivial program (HTTP/TLS comes to mind), and it would be similar to Rust except that CPAN is very slow-paced these days. I'm curious to see how it all evolves.
    - steveklabnik 2y ago
      > it's very tedious to vet them all, It is also very tedious to vet a large dependency, as there's so much code to review. > It all works well if everyone wants to play nice, but this doesn't scale. There are tools like cargo-crev to help scale up the "hey I reviewed the code here and if you trust me, you can trust my review." > I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Yes, on purpose. Rust will try to unify them as much as possible, but if two dependencies rely on incompatible versions, you'll get two. Note that they'll be different types, so if you try and use a foov1 where a foov2 is needed, you'll get a compile error. > Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. This goes both ways: you could also have some code depending on an older, secure version, and a newer one is the one with the vulnerabilty. But also, the way you phrase this makes me think you may misunderstand some details about how this happens: each crate doesn't pin its own version, exactly. The entire dependency graph is looked at holistically. But as I said above, you can still get situations like this, so this is very nitpicky. > And they got burned early enough so vendoring is a Good Thing now. You can absolutely trivially vendor your Rust dependencies as well. It's built into the tooling. > I'm curious to see how it all evolves. Absolutely. Me too.