Hacker News Reader

Comment by wasmperson | Hacker News Reader

There was a recent talk which explored this question (Dependency Cultures, by Richard Feldman):

https://www.youtube.com/watch?v=E82ly38YEEQ

Summary: it's cultural. Rust likely inherited the practice from Nodejs, who inherited it from Ruby. I think in Rust online spaces in particular there is also this undercurrent of "you're not smart enough to use certain parts of the language, so download libraries that handle that stuff for you."

View on HN

The language also takes backwards compatibility very seriously, anything that goes into std "must be maintained forever". It is also argued that a large stdlib means the maintainers have less time to work on the language itself.

I understand not every language can have Go's amazing stdlib, but I would much prefer Pyhton's approach where every now and then some package/function from the stdlib gets deprecated/removed. Rust's 3rd party ecosystem is the worst thing from the language, worse than the compile times.

The "npm-ness" of Cargo (centralized and standardized dependency management used at every opportunity) is generally pitched as one of the primary developer experience advantages over C++.

The thing is, just having a centralized standardized dependency manager doesn't in itself force your ecosystem into this dangerous "micro dependency" pattern. Java'd Maven is also a centralized standardized dependency manager, as is Python's PyPI. However, neither the Java nor the Python ecosystem have devolved into having dependency libraries with 4 methods in them becoming used and required by major libraries.

For those missing the npm like experience in C, they can use apt, yum, dnf, winget, nuget, conan, vcpkg.

In a large enough C codebase, you may even find yourself somehow using all of these simultaneously. :)

Yep.

i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Conan, Meson, Ninja, Bazel, meta-build tool / dependency manager #231 etc. etc. And then you have to deal with all the modern C++ and STL footguns.

It never ends .·°՞(っ-ᯅ-ς)՞°·.

I'd just select a tool, vendor the libraries I need to the codebase and call it a day. Did these for Eigen, liboption++, Catch2, Easylogging++ (now archived and not maintained anymore, sadly).

Build a simple makefile, and you're off to the races.

At least, for my cases, that is.

None of those (other than submodules which is just vendoring) does dependency management. They are more configuration management than anything. C, Python, Perl (and maybe ruby?) relies on flag switches and environment variables to find all the necessary files and modules for compiling/running a script. Cmake and autoconf just configure those.

With NPM and Rust's focus on project's level dependencies, there's no longer emphasis on API stability. Instead we have breakage every months, forcing everyone on the upgrade treadmill. It's easier to audit C library because they focus mostly on security updates instead of redesigning the API for the nth time.

vcpkg is pretty good. cmake is complex but very flexible. just need an llm to help and it's pretty much solved (if your dep is in autopkg)

I'll take all that over downloading and immediately executing random unreviewed code any day.

All of those can (and some do) wget source code from the internet and run it if you kick off their build pipeline. People just tend to use these tools differently.

Nothing is preventing anyone from distributing Rust crates as standard system packages, like some distros do with Python.

I think Debian is actually shipping rust libs in their repositories: https://wiki.debian.org/Rust Now Rust developers can also enjoy having to deal with popular packages that are years out of date/missing from popular repositories/getting deleted.

Of course they can be made to do anything but that's not what they are designed for and as a result they also build a culture that frowns upon doing that. Debian and other Linux distributions would have never had the policy do handle dependency resolution themselves if contemporary build systems automatically fetched everything automatically rather than being designed to use dependencies provided by the user.

xmake, build2, whatever msvc and xcode insist upon…

Reply on news.ycombinator.com