5 ms·

Who is doing dependencies right in your opinion? Because it feels like it's a complaint I hear about every language.

coolreader18 5y ago
Might be biased/stereotypical, but Rust's cargo does dependencies really well. It's as easy as npm to add new dependencies, but there aren't thousands needed to do anything, and if you take a look at your Cargo.lock/`cargo tree` you can really get to know each of them and what they do or why they're pulled in. I'm still bloat-wary, maybe as a leftover from doing webdev, but with less transitive dependencies in the first place you can actually go through and prune things that aren't needed, or open PRs to transitive deps to prune from their trees or update deps to the latest version to deduplicate your tree. (If there are multiple semver-incompatible versions in a dep tree, they just both get compiled in - for most apps though, you should be able to get the number of duplicates to 0 or almost that.)
- aprdm 5y ago
  I wonder how Cargo will be regarded as in 2-5 years if it gets anywhere near the number of projects/libraries that say Python or Javascript has.
  - pjmlp 5y ago
    You can either go to lunch or buy a Threadripper server to be able to compile a full project from scratch, everytime you want to check something. Unless by then cargo has already learned how to deal with binary crates.
- colin_mccabe 5y ago
  If compile time is the problem, Rust is not (yet?) the solution. I agree that Cargo is much better than the Go build system, though.
  - morelisp 5y ago
    coolreader18's points are mostly about the culture of JavaScript vs. Rust (where Go also hews much closer to the Rust side). Setting aside lockfiles vs. MVS (which won't get "solved" in an HN debate), why do you prefer Cargo to go mod?
- pjmlp 5y ago
  For me, it only gets the "really well" when it also does binary dependencies vcpkg/conan style.
  - Nullabillity 5y ago
    Having tried both, focusing on source dependencies is the only way to make sure that dependency sources are universally available and buildable, which makes a huge difference in the long run. Just look at NuGet's issues getting SourceLink adopted. Binary caching á la Nix can work, but I can't really see that working out without Nix's commitment to environment purity.
    - pjmlp 5y ago
      When one is lucky to use server hardware as workstation, and works in domains that don't depend on selling binary libraries for their business.
      - Nullabillity 5y ago
        > When one is lucky to use server hardware as workstation Sounds like something is pretty screwed up if you're running cargo clean as part of your regular workflow. > works in domains that don't depend on selling binary libraries for their business Play stupid games, win stupid prizes? Meh.
ufmace 5y ago
IMO, Ruby Bundler was the first language / ecosystem to really get dependencies right. AFAIK, they were the first to have a lockfile locking the version of each dependency and a Gemfile with flexible version specification for dependencies, and a tool to handle installing the right version of everything and making sure you run in the context of your specified gems every time, no matter what else is installed on the machine. Rust Cargo does about as well, probably the best for a compiled language. NPM could be about as good too - it almost feels like they deserve a point off for the ridiculously huge number of tiny packages required to do anything, though that isn't really the dependency manager's fault.
- pjmlp 5y ago
  CPAN and Maven did it first.
  - morelisp 5y ago
    Maven doesn't have a lockfile, from just reading the files it's difficult to find the version of a dependency you'll actually get.
    - pjmlp 5y ago
      It doesn't need one, when version is already part of dependency definition. If you want to be sure of what version you get, use it.
      - morelisp 5y ago
        Transitive dependencies are not going to be in your POM file normally, and Maven has a confusing algorithm for resolving them (essentially, first found in a BFS over the dependency tree). And if you do include them, that will silently override transitive dependencies on more recent versions, which is rarely what is wanted. Yes, you can ask the tool to print them. This is way worse than any of the other systems being discussed, where you can read a file in the repo.

Might be biased/stereotypical, but Rust's cargo does dependencies really well. It's as easy as npm to add new dependencies, but there aren't thousands needed to do anything, and if you take a look at your Cargo.lock/`cargo tree` you can really get to know each of them and what they do or why they're pulled in. I'm still bloat-wary, maybe as a leftover from doing webdev, but with less transitive dependencies in the first place you can actually go through and prune things that aren't needed, or open PRs to transitive deps to prune from their trees or update deps to the latest version to deduplicate your tree. (If there are multiple semver-incompatible versions in a dep tree, they just both get compiled in - for most apps though, you should be able to get the number of duplicates to 0 or almost that.)

aprdm 5y ago
I wonder how Cargo will be regarded as in 2-5 years if it gets anywhere near the number of projects/libraries that say Python or Javascript has.
- pjmlp 5y ago
  You can either go to lunch or buy a Threadripper server to be able to compile a full project from scratch, everytime you want to check something. Unless by then cargo has already learned how to deal with binary crates.
colin_mccabe 5y ago
If compile time is the problem, Rust is not (yet?) the solution. I agree that Cargo is much better than the Go build system, though.
- morelisp 5y ago
  coolreader18's points are mostly about the culture of JavaScript vs. Rust (where Go also hews much closer to the Rust side). Setting aside lockfiles vs. MVS (which won't get "solved" in an HN debate), why do you prefer Cargo to go mod?
pjmlp 5y ago
For me, it only gets the "really well" when it also does binary dependencies vcpkg/conan style.
- Nullabillity 5y ago
  Having tried both, focusing on source dependencies is the only way to make sure that dependency sources are universally available and buildable, which makes a huge difference in the long run. Just look at NuGet's issues getting SourceLink adopted. Binary caching á la Nix can work, but I can't really see that working out without Nix's commitment to environment purity.
  - pjmlp 5y ago
    When one is lucky to use server hardware as workstation, and works in domains that don't depend on selling binary libraries for their business.
    - Nullabillity 5y ago
      > When one is lucky to use server hardware as workstation Sounds like something is pretty screwed up if you're running cargo clean as part of your regular workflow. > works in domains that don't depend on selling binary libraries for their business Play stupid games, win stupid prizes? Meh.

ufmace 5y ago

IMO, Ruby Bundler was the first language / ecosystem to really get dependencies right. AFAIK, they were the first to have a lockfile locking the version of each dependency and a Gemfile with flexible version specification for dependencies, and a tool to handle installing the right version of everything and making sure you run in the context of your specified gems every time, no matter what else is installed on the machine. Rust Cargo does about as well, probably the best for a compiled language. NPM could be about as good too - it almost feels like they deserve a point off for the ridiculously huge number of tiny packages required to do anything, though that isn't really the dependency manager's fault.

pjmlp 5y ago
CPAN and Maven did it first.
- morelisp 5y ago
  Maven doesn't have a lockfile, from just reading the files it's difficult to find the version of a dependency you'll actually get.
  - pjmlp 5y ago
    It doesn't need one, when version is already part of dependency definition. If you want to be sure of what version you get, use it.
    - morelisp 5y ago
      Transitive dependencies are not going to be in your POM file normally, and Maven has a confusing algorithm for resolving them (essentially, first found in a BFS over the dependency tree). And if you do include them, that will silently override transitive dependencies on more recent versions, which is rarely what is wanted. Yes, you can ask the tool to print them. This is way worse than any of the other systems being discussed, where you can read a file in the repo.