[bgwalter]

If only a reason were given. This is the original:

> Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update.

What has changed? Why is 130 packages for a crypto application acceptable?

[jeroenhd]

That's not a Rust problem, that's a sequoia problem.

As for why, probably the same reason the dependency tree for gnupg (generate with `debtree -R -b gnupg` but grepping out all the gcc/mingw dependencies) looks like this: https://static.jeroenhd.nl/hn/gnupg.svg There's probably a good reason why I need libjpeg62, libusb-1.0-0-dev, and libgmp3 to compile gnupg, though they're hidden away from the usual developer docs in the form of transitive dependencies; complex software just tends to include external dependencies rather than reinventing the wheel.

[ok123456]

Is it? Rust, or rather its online acolytes, deems a simple linked list "too complicated" for mere mortals, and routinely tells people "just" to use a crate that does it for you.

To me, this sounds like "leftpad" but for CS1 data structures.

[pornel]

Debian's tooling for packaging Cargo probably got better, so this isn't as daunting as it used to be.

Another likely thing is understanding that the unit of "package" is different in Rust/Cargo than traditionally in C and Debian, so 130 crates aren't as much code as 130 Debian packages would have been.

The same amount of code, from the same number of authors, will end up split into more smaller packages (crates) in Rust. Where a C project would split itself into components internally in a way that's invisible outside (multiple `.h` files, in subdirectories or sub-makefiles), Rust/Cargo projects split themselves into crates (in a Cargo workspace and/or a monorepo), which happen to be visible externally as equal to a package. These typically aren't full-size dependencies, just a separate compilation unit. It's like cutting a pizza into 4 or 16 slices. You get more slices, but that doesn't make the pizza bigger.

From security perspective, I've found that splitting large projects into smaller packages actually helps review the code. Each sub-package is more focused on one goal, with a smaller public API, so it's easier to see if it's doing what it claims to than if it was a part of a monolith with a larger internal API and more state.

[bonzini]

Probably because 120 (*) have been added in the intervening 4 years.

(*) random number