6 ms·

Similar feeling here. Cargo makes it so simple to add tons of dependencies that it is really hard not to do it. But that does not stop here: even if I try to b

by palata 2y ago

Similar feeling here. Cargo makes it so simple to add tons of dependencies that it is really hard not to do it. But that does not stop here: even if I try to be careful with adding dependencies, a couple dependencies are likely to pull tens of transitive dependencies each. "Then don't depend on them", you say. Sure, but that means I won't write my project, because I won't write those things from scratch. I could probably audit the dependency (if it wasn't pulling 50 packages itself), but I can't reasonably write it myself. It is different with C++: I can often find dependencies that don't pull tens of transitive dependencies in C++. Maybe because it's harder to add dependencies, maybe because the ecosystem is more mature, I don't know. But it feels like the philosophy in Rust is to pull many small packages, so it doesn't seem like it will change. And that's a pity, because I like Rust-the-language better than C++-the-language. It just feels like I trade "it's not memory-safe" for "you have to pull tons of random code from the Internet".

jampekka 2y ago
I take bit less unstable dependencies over the total mess of C++ dependencies with CMake, shared libraries, version conflicts etc any time. There's probably also a bit of an illusion about C++ transitive dependencies due to them usually being precompiled (because compiling them is such pain).
- ChocolateGod 2y ago
  The whole pkgconfig, cmake, autotools etc ecosystem is insane compared to how Rust and Go do things. It's part of the reason why software distribution on Linux has been pushed to using containers, removing the point of having shared libraries. I think Google with it's C++ replacement (Carbon) plans on doing it's own system.
  - skydhash 2y ago
    From my point of view, the issue stems from developers wanting to control distribution. Fine if it's for your own usage, not really if you're planning for others to use it. You will find the most convoluted build system just because they have a pet platform they want to specially support making it hell to do anything on others. It could be better, but the current solutions (npm, go, python,...) favor only the developers, not the maintainers and packagers.
    - ChocolateGod 2y ago
      There's examples of maintainers/packagers effectively sabotaging other peoples projects when making packages for distros, whether that's shipping them broken, ancient versions etc. e.g. Bottles, WebkitGTK (distros liked keeping this one held back even though doing so is a security risk) IMHO it shouldn't be the responsibility of the OS vendor to package third party applications.
      - jampekka 2y ago
        Distro maintainers/packagers are who keep the current software stacks running. It's rather amazing how they manage to keep the billion or so lines of separately written code working in unison. That said, the labor needed to keep the stuff together could be reduced a lot by the more ergonomical and universal packaging and distribution methods like Cargo (and, dare I say, npm). I think some kind of a better bridge between developers and distros could be found here.
        skydhash 2y ago
        > I think some kind of a better bridge between developers and distros could be found here. I don’t think there’s a need to do so. Only discipline is needed, by using stable and mature dependencies, and documenting the building process. And maybe some guides/scripts for the most popular distros.
        ChocolateGod 2y ago
        > > I think some kind of a better bridge between developers and distros could be found here. Every tom dick and harry is making their own distro these days (even if they're just respins of Arch with Calamares and some questionable theme settings), why add more work onto developers? We have things like Flatpak and Docker now that let application developers ignore the distros and stop them breaking things, unless you're Ubuntu whom is constantly begging to get purchased by Microsoft.
  - palata 2y ago
    > It's part of the reason why software distribution on Linux has been pushed to using containers My understanding of people distributing their software in containers is that they can't be arsed to learn how to do it properly. They would install their software and ship the entire computer if that was cost effective.
    - jampekka 2y ago
      What needs to be "learned properly" is sadly a huge pile of incoherent legacy cruft that ideally wouldn't be there at all. This is not to denigrate the huge and critical effort that makes current computing possible, and that is likely unavoidable in the real world. But software distribution needs to evolve.
      - palata 2y ago
        > What needs to be "learned properly" is sadly a huge pile of incoherent legacy cruft I don't find it incoherent, nor huge. Unless the bar for "huge" is "anything that requires more attention than asking an LLM and copy-pasting its answer", maybe.
    - rcxdude 2y ago
      It's not a case of 'learning to do it properly', it's a case of a huge amount of effort to deal with arbitrary differences between distros, as well as fighting with distro policies that would rather ship the software with known bugs than allow two versions of a library to exist on the system.
      - palata 2y ago
        > it's a case of a huge amount of effort to deal with arbitrary differences between distros That is not at all a problem for open source stuff: build your project correctly, and let distros do their job. Still, open source projects are too often doing it wrong, because nobody can be arsed to learn. > as well as fighting with distro policies that would rather ship the software with known bugs than allow two versions of a library to exist on the system. Sounds like if you need this, you're doing it wrong. If it's a major update (e.g. 2.3.1 to 3.0.0), it's totally possible to have a new package (say `python2` and `python3`). If your users need two versions of a library that are in the same major version (e.g. 2.3.1 and 2.5.4), then you as a developer are doing it wrong. No need to fight, just learn to do it properly.
antonvs 2y ago
> Sure, but that means I won't write my project, because I won't write those things from scratch. You need to think a bit harder about that, to help you decide whether your position is rational.
- MeetingsBrowser 2y ago
  This confuses me as well. Is the implied solution to choose a language where you are forced to write those things from scratch?
  - palata 2y ago
    My point is that if, in the language, everybody is incentivise to use fewer dependencies, then a random library that I would not write myself (because it is an entire project in itself) would have fewer dependencies. Because it is not the case, either I take that library and accept its transitive dependencies, or I don't have a library at all. In Rust, I'm sometimes actually tempted to wrap a C/C++ library (and its few dependencies) instead of getting the Rust alternative (and its gazillion dependencies).
- palata 2y ago
  And you need to think a bit about that (probably not very hard), to help you decide whether I'm irrational or whether you may not have totally understood my point.
perrygeo 2y ago
> the philosophy in Rust is to pull many small package I'm not sure it's a philosophy, more a pragmatic consideration for compilation speeds. Anyone who's done a non-trivial amount of Rust knows that moment when the project gets too big and needs to split into separate crates. It's kinda sad that you can't organize code according to proper abstractions, many times I feel forced to refactor for compiler performance.
X0Refraction 2y ago
This was linked from the top comment on the Rust subreddit: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies I think it makes a good point that some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. To some degree that is a plus though as you likely trust the maintainers of your OS distribution to provide stable, supported libraries. As other commenters have said, perhaps this is an area where the Rust maintainers could provide some kind of extended standard library where they don't guarantee backwards compatibility forever, but do provide guarantees about ongoing fixes for security issues.
- palata 2y ago
  > some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. Not in my case. I manually compile all the dependencies (either because I need to cross-compile, or because I may need to patch them, etc). So I clearly see all the transitive dependencies I need in C++. And I need a lot less than in Rust, by a long shot.
  - elabajaba 2y ago
    Part of the rust dependency issue is that the compiler only multithreads at the crate level currently (slowly being improved on nightly, but there's still some bugs before they can roll out the parallel compiler), so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile. edit: Also, `cargo-vet` is useful for distributed auditing of crates. There's also `cargo-crev`, but afaik it doesn't have buy in from the megacorps like cargo-vet and last I checked didn't have as many/as consistent reviews. https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
    - zahlman 2y ago
      > so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile. In practice, does this make it feasible to pick and choose the pieces you actually need?
imtringued 2y ago
I have been wasting 6 hours yesterday on getting the bullet examples to compile outside of bullet itself with no success. It's more likely that a lot of software simply doesn't get written because C++ and CMake are a pain in the ass.
- palata 2y ago
  I find CMake pretty easy, and I only use a few core features from it. Usually the pain comes from completely wrong setups by people who didn't learn the basic. But it's true of everything, I think.

by palata 2y ago

jampekka 2y ago

I take bit less unstable dependencies over the total mess of C++ dependencies with CMake, shared libraries, version conflicts etc any time. There's probably also a bit of an illusion about C++ transitive dependencies due to them usually being precompiled (because compiling them is such pain).

ChocolateGod 2y ago
The whole pkgconfig, cmake, autotools etc ecosystem is insane compared to how Rust and Go do things. It's part of the reason why software distribution on Linux has been pushed to using containers, removing the point of having shared libraries. I think Google with it's C++ replacement (Carbon) plans on doing it's own system.
- skydhash 2y ago
  From my point of view, the issue stems from developers wanting to control distribution. Fine if it's for your own usage, not really if you're planning for others to use it. You will find the most convoluted build system just because they have a pet platform they want to specially support making it hell to do anything on others. It could be better, but the current solutions (npm, go, python,...) favor only the developers, not the maintainers and packagers.
  - ChocolateGod 2y ago
    There's examples of maintainers/packagers effectively sabotaging other peoples projects when making packages for distros, whether that's shipping them broken, ancient versions etc. e.g. Bottles, WebkitGTK (distros liked keeping this one held back even though doing so is a security risk) IMHO it shouldn't be the responsibility of the OS vendor to package third party applications.
    - jampekka 2y ago
      Distro maintainers/packagers are who keep the current software stacks running. It's rather amazing how they manage to keep the billion or so lines of separately written code working in unison. That said, the labor needed to keep the stuff together could be reduced a lot by the more ergonomical and universal packaging and distribution methods like Cargo (and, dare I say, npm). I think some kind of a better bridge between developers and distros could be found here.
      - skydhash 2y ago
        > I think some kind of a better bridge between developers and distros could be found here. I don’t think there’s a need to do so. Only discipline is needed, by using stable and mature dependencies, and documenting the building process. And maybe some guides/scripts for the most popular distros.
      - ChocolateGod 2y ago
        > > I think some kind of a better bridge between developers and distros could be found here. Every tom dick and harry is making their own distro these days (even if they're just respins of Arch with Calamares and some questionable theme settings), why add more work onto developers? We have things like Flatpak and Docker now that let application developers ignore the distros and stop them breaking things, unless you're Ubuntu whom is constantly begging to get purchased by Microsoft.
- palata 2y ago
  > It's part of the reason why software distribution on Linux has been pushed to using containers My understanding of people distributing their software in containers is that they can't be arsed to learn how to do it properly. They would install their software and ship the entire computer if that was cost effective.
  - jampekka 2y ago
    What needs to be "learned properly" is sadly a huge pile of incoherent legacy cruft that ideally wouldn't be there at all. This is not to denigrate the huge and critical effort that makes current computing possible, and that is likely unavoidable in the real world. But software distribution needs to evolve.
    - palata 2y ago
      > What needs to be "learned properly" is sadly a huge pile of incoherent legacy cruft I don't find it incoherent, nor huge. Unless the bar for "huge" is "anything that requires more attention than asking an LLM and copy-pasting its answer", maybe.
  - rcxdude 2y ago
    It's not a case of 'learning to do it properly', it's a case of a huge amount of effort to deal with arbitrary differences between distros, as well as fighting with distro policies that would rather ship the software with known bugs than allow two versions of a library to exist on the system.
    - palata 2y ago
      > it's a case of a huge amount of effort to deal with arbitrary differences between distros That is not at all a problem for open source stuff: build your project correctly, and let distros do their job. Still, open source projects are too often doing it wrong, because nobody can be arsed to learn. > as well as fighting with distro policies that would rather ship the software with known bugs than allow two versions of a library to exist on the system. Sounds like if you need this, you're doing it wrong. If it's a major update (e.g. 2.3.1 to 3.0.0), it's totally possible to have a new package (say `python2` and `python3`). If your users need two versions of a library that are in the same major version (e.g. 2.3.1 and 2.5.4), then you as a developer are doing it wrong. No need to fight, just learn to do it properly.

antonvs 2y ago

> Sure, but that means I won't write my project, because I won't write those things from scratch. You need to think a bit harder about that, to help you decide whether your position is rational.

MeetingsBrowser 2y ago
This confuses me as well. Is the implied solution to choose a language where you are forced to write those things from scratch?
- palata 2y ago
  My point is that if, in the language, everybody is incentivise to use fewer dependencies, then a random library that I would not write myself (because it is an entire project in itself) would have fewer dependencies. Because it is not the case, either I take that library and accept its transitive dependencies, or I don't have a library at all. In Rust, I'm sometimes actually tempted to wrap a C/C++ library (and its few dependencies) instead of getting the Rust alternative (and its gazillion dependencies).
palata 2y ago
And you need to think a bit about that (probably not very hard), to help you decide whether I'm irrational or whether you may not have totally understood my point.

perrygeo 2y ago

> the philosophy in Rust is to pull many small package I'm not sure it's a philosophy, more a pragmatic consideration for compilation speeds. Anyone who's done a non-trivial amount of Rust knows that moment when the project gets too big and needs to split into separate crates. It's kinda sad that you can't organize code according to proper abstractions, many times I feel forced to refactor for compiler performance.

X0Refraction 2y ago

This was linked from the top comment on the Rust subreddit: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies I think it makes a good point that some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. To some degree that is a plus though as you likely trust the maintainers of your OS distribution to provide stable, supported libraries. As other commenters have said, perhaps this is an area where the Rust maintainers could provide some kind of extended standard library where they don't guarantee backwards compatibility forever, but do provide guarantees about ongoing fixes for security issues.

palata 2y ago
> some of the difference here is just perception due to dependencies in C/C++ being less immediately visible since they're dynamically loaded. Not in my case. I manually compile all the dependencies (either because I need to cross-compile, or because I may need to patch them, etc). So I clearly see all the transitive dependencies I need in C++. And I need a lot less than in Rust, by a long shot.
- elabajaba 2y ago
  Part of the rust dependency issue is that the compiler only multithreads at the crate level currently (slowly being improved on nightly, but there's still some bugs before they can roll out the parallel compiler), so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile. edit: Also, `cargo-vet` is useful for distributed auditing of crates. There's also `cargo-crev`, but afaik it doesn't have buy in from the megacorps like cargo-vet and last I checked didn't have as many/as consistent reviews. https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
  - zahlman 2y ago
    > so most libraries split themselves up into a ton of small crates because otherwise they just take too long to compile. In practice, does this make it feasible to pick and choose the pieces you actually need?

imtringued 2y ago

I have been wasting 6 hours yesterday on getting the bullet examples to compile outside of bullet itself with no success. It's more likely that a lot of software simply doesn't get written because C++ and CMake are a pain in the ass.

palata 2y ago
I find CMake pretty easy, and I only use a few core features from it. Usually the pain comes from completely wrong setups by people who didn't learn the basic. But it's true of everything, I think.