Hacker News Reader

Comment by frankjr | Hacker News Reader

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinders Rust's adoption (as seen in this case). It's especially ridiculous considering Rust positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers for any non trivial project to not be malicious.

https://github.com/koverstreet/bcachefs-tools/blob/b422b19f6...

View on HN

Still, if you include transitive dependencies you end up with a total of 90 dependencies[0] which is unheard of in systems programming. This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools.

[0]:https://github.com/gentoo/gentoo/blob/master/sys-fs/bcachefs...

> with a total of 90 dependencies[0] which is unheard of in systems programming

If the comparison is with C/C++ then the comparison is flawed:

- some you would never see in C/C++ because there's no point to them (e.g. safe bindings to system libraries)

- some are the same dependency but split in multiple crates to improve compile times (e.g. `anstyle`, `clap` and `regex`)

- some in C/C++ would just be vendored due to the difficulty of package management (see for example [0])

> This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools.

I don't know how Gentoo's build system works, but Cargo resolves the versions for *all dependencies*, including those that are conditionally compiled (e.g. based on the target OS). This is because the `Cargo.lock` file, which contains the actual dependencies versions used, is supposed to be versioned in e.g. git, and thus needs to be cross platform and be the same for everyone compiling the crate.

[0]:https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-...

The winapi dependency comes from the rust tooling (cargo specifically) putting a great value on portability, and practical concerns like people collaborating from different platforms on the same project. Many Rust projects check their Cargo.lock into git (recommended for binaries, and also many libraries do it). Now imagine if the Cargo.lock changes depending on the platform, which one would you track in git?

Now, there is the separate concern of cargo-vendor downloading the winapi crate, which it does, also on Linux. It doesn't have to because winapi is never built, yet it still does it. That one I agree is a bit wasteful, but it's a known issue.

Where are those things in the standard library of C or C++, which most software is written in?

Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.

Parsing command line arguments, reading/manipulating binary data, memset_s are of course all available in the C standard library. I’m not familiar with rust, but if it’s true that dependencies are required for those types of basic operations... yikes, to say the least. If you include boost (which, admittedly, is a heavy dependency, but still a single one), everything mentioned is possible.

Just to be clear about it, Rust has the same level of this stuff in the standard library as C does. Like, the equivalent of argc/argv is in the rust standard library. The library being included is more like getopt conceptually; a package built on top of that that makes things nicer.

> If you include boost (which, admittedly, is a heavy dependency, but still a single one)

Then in principle, we could curate a set of useful Rust crates, treat the set as a single dependency, and be on the same page as C++ with Boost.

> positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers

It doesn't require anything. You can write those things yourself if you want. And for some critical things you should.

But given the tiny number of languages with logging, uuids, and error reporting built in... what are you taking about? They're doing just fine.

Nonsense. If these were written in C, and depended on exact versions of getopt, log4c, libuuid, etc and refused to vendor them do you think that would be any easier to package?

This is a result of every Linux distros' self-centred requirement for the entire world to be packaged by them, and a refusal to accept vendoring.

Python has exactly the same problem. You can't even `pip install` on Debian any more because they insist on copying a random selection of Python packages into Apt and they can conflict.

> You can't even `pip install` on Debian any more because they insist on copying a random selection of Python packages into Apt and they can conflict.

And, they insist on not including venv by default, which IMO seems like a tiny little "fuck you" to users.

Reply on news.ycombinator.com