4 ms·

Agreed with your point about Cargo. It's a double edged sword. We absolutely have an NPM/leftpad culture in Rust. Is that better or worse than C and C++ where

Agreed with your point about Cargo. It's a double edged sword. We absolutely have an NPM/leftpad culture in Rust. Is that better or worse than C and C++ where dependencies are so painful that you end up reinventing the wheel most of the time? I honestly don't know.

skohan 6y ago
Yes I think it's a really difficult problem to be honest. I am definitely grateful for how easy it is to make rust projects reproducible, but it's not without disadvantages.
pjmlp 6y ago
Dependencies are relatively easy, actually. Just most don't bother learning how to do it, and do it PHP style with header includes. On UNIX systems just using pkg-config and similar tools, or just adopt either conan or vcpkg, which contrary to cargo also support binary libraries out of the box. Plus vendoring C and C++ libraries is not a dark science, only known by old druids.
- skohan 6y ago
  Maybe I've just missed it, but I have found pkg-config difficult to use and poorly documented. It's fine if you are installing things with a package manager, but I found it took some trail-and-error to figure out how to do this for my own lbraries, or for things built manually from source. Also with c/c++ style system dependencies, I feel like there are a lot of issues with things like version conflicts which are solved much more simply by a package manager like cargo. I agree that it's functional, but to say relatively easy I think is a bit of a stretch.
  - pjmlp 6y ago
    Cargo also has issues when two crates have incompatible dependencies, or at very least you end with the same crate being compiled a couple of times, as the hashes don't match up. Usually when compiling from source many libraries provide pkg-config configuration files on "make install".
    - skohan 6y ago
      But with Cargo it's scoped to the crate you're compiling right? So it only matters if there's a collision in the dependencies of a given project. Isn't it the case with pkg-config that everything is stored in a central location? In any case, I think you can't seriously argue that the c/c++ dependency management solution is anywhere close to running `cargo build`/`cargo run` in terms of simplicity.
      - pjmlp 6y ago
        Yes I surely can, because Conan and vcpkg do exist, and contain all major well known libraries in the C and C++ communities. Specially the C++ community has seen lack of something like cargo as weaknesses and moved to sort it out.
    - Animats 6y ago
      Yes. Rust encourages version pinning. You go to "crates.io", and it gives you a specific version number to put in your "cargo.toml" file. Now you're nailed to that version for your program or crate. Crates have their own "cargo.toml" file, with their own versions, and it's quite possible to pull in multiple versions. Right now, I'm using the latest version of "reqwest" known to "crates.io." It's pulling in Tokio v0.2.23, not the new tokio v1.0.0. No surprise there, the new version only came out yesterday. So we'll see how the new version works at some time in the future. It's good to get to version 1. The semantic versioning rules allow breaking changes without changing the first digit when the first digit is 0. Typical complaint on forums: "bignum happens to use rand internally, and it happens to only use version 0.5.0, with restrictions against using a higher version due to breaking changes." Rust still has many low-level crates at version 0.x.x, from "bytes" to "uuid". Reaching 1 indicates greater stability.
      - zozbot234 6y ago
        > Yes. Rust encourages version pinning. Rust makes version pinning feasible, e.g. by allowing multiple versions of the same package in a build (not all module systems have this feature!) but doesn't encourage it. You've identified a problem with using 0.x.y-versioned packages as dependencies (which means de-facto opting out of semver), but that's not a problem with Rust specifically; it could occur in any language.

skohan 6y ago

Yes I think it's a really difficult problem to be honest. I am definitely grateful for how easy it is to make rust projects reproducible, but it's not without disadvantages.

pjmlp 6y ago

Dependencies are relatively easy, actually. Just most don't bother learning how to do it, and do it PHP style with header includes. On UNIX systems just using pkg-config and similar tools, or just adopt either conan or vcpkg, which contrary to cargo also support binary libraries out of the box. Plus vendoring C and C++ libraries is not a dark science, only known by old druids.

skohan 6y ago
Maybe I've just missed it, but I have found pkg-config difficult to use and poorly documented. It's fine if you are installing things with a package manager, but I found it took some trail-and-error to figure out how to do this for my own lbraries, or for things built manually from source. Also with c/c++ style system dependencies, I feel like there are a lot of issues with things like version conflicts which are solved much more simply by a package manager like cargo. I agree that it's functional, but to say relatively easy I think is a bit of a stretch.
- pjmlp 6y ago
  Cargo also has issues when two crates have incompatible dependencies, or at very least you end with the same crate being compiled a couple of times, as the hashes don't match up. Usually when compiling from source many libraries provide pkg-config configuration files on "make install".
  - skohan 6y ago
    But with Cargo it's scoped to the crate you're compiling right? So it only matters if there's a collision in the dependencies of a given project. Isn't it the case with pkg-config that everything is stored in a central location? In any case, I think you can't seriously argue that the c/c++ dependency management solution is anywhere close to running `cargo build`/`cargo run` in terms of simplicity.
    - pjmlp 6y ago
      Yes I surely can, because Conan and vcpkg do exist, and contain all major well known libraries in the C and C++ communities. Specially the C++ community has seen lack of something like cargo as weaknesses and moved to sort it out.
  - Animats 6y ago
    Yes. Rust encourages version pinning. You go to "crates.io", and it gives you a specific version number to put in your "cargo.toml" file. Now you're nailed to that version for your program or crate. Crates have their own "cargo.toml" file, with their own versions, and it's quite possible to pull in multiple versions. Right now, I'm using the latest version of "reqwest" known to "crates.io." It's pulling in Tokio v0.2.23, not the new tokio v1.0.0. No surprise there, the new version only came out yesterday. So we'll see how the new version works at some time in the future. It's good to get to version 1. The semantic versioning rules allow breaking changes without changing the first digit when the first digit is 0. Typical complaint on forums: "bignum happens to use rand internally, and it happens to only use version 0.5.0, with restrictions against using a higher version due to breaking changes." Rust still has many low-level crates at version 0.x.x, from "bytes" to "uuid". Reaching 1 indicates greater stability.
    - zozbot234 6y ago
      > Yes. Rust encourages version pinning. Rust makes version pinning feasible, e.g. by allowing multiple versions of the same package in a build (not all module systems have this feature!) but doesn't encourage it. You've identified a problem with using 0.x.y-versioned packages as dependencies (which means de-facto opting out of semver), but that's not a problem with Rust specifically; it could occur in any language.