[arccy]

from part 2:

> Worse, early prototypes already pulled in nearly a thousand third-party Rust crates, many of which were transitive dependencies and largely unvetted, posing potential supply-chain risks.

Rust really going for the node ecosystem's crown in package number bloat

[dralley]

Rust is nowhere close to Node in terms of package number bloat. Most Rust libraries are actually useful and nontrivial and the supply chain risk is not necessarily as high for the simple reason that many crates are split up into sub-crates.

For example, instead of having one library like "hashlib" that handles all different kinds of hashing algorithms, the most "official" Rust libraries are broken up into one for sha1, one for sha2, one for sha3, one for md5, one for the generic interfaces shared by all of them, etc... but all maintained by the same organization: https://github.com/rustcrypto/

Most crypto libraries do the same. Ripgrep split off aho-corastick and memchr, the regex crate has a separate pcre library, etc.

Maybe that bumps the numbers up if you need more than one algorithm, but predominantly it is still anti-bloat and has a purpose...

[rustystump]

While i agree the exact line “rust libraries are useful and non-trivial” i have heard from all over the place as if the value of a library is how complex it is. The rust community has an elitist bent to it or a minority is very vocal.

Supply chain attacks are real for all package registries. The js ones had more todo with registry accounts getting hacked than the compromised libraries being bad or useless.

[egorfine]

I am sensing a "is-odd" and "is-even" vibes from that approach.

[jasomill]

Not at all.

Most programs only use one or a few hash functions, so grouping each family into a separate crate reduces compliation time for the majority of users. Could also help when auditing the removal of vulnerable hash functions.

As for ripgrep, the organization is quite sensible:

1. one crate to define an interface for regex matchers

2. one crate to implement the native matcher

3. one crate to implement the PCRE2 matcher

4. one crate to define a safe interface to the underlying PCRE2 library

Depending on the application, any one of 1+2+3+4, 1+2, 1+3+4, or 4 alone could be useful.

[egorfine]

Yes I perfectly understand the reasoning and technically it is sound.

It becomes insane once you start thinking of real life implications, specifically supply chain attacks.

Although it's only marginally more insane than the other ecosystems.

[dralley]

The alternative is sometimes that people just copy and paste code from libraries that never gets updated.

[Aperocky]

It really is about time that somebody do something about it.

Start with tokio. Please vend one dependency battery included, and vendor in/internalize everything, thanks.

[okanat]

There is a difference between individual packages coming out of a single project (or even a single Cargo workspace) vs them coming out of completely different people.

The former isn't a problem, it is actually desirable to have good granularity for projects. The latter is a huge liability and the actual supply chain risk.

For example, Tokio project maintains another popular library called Prost for Protobufs. I don't think having those as two separate libraries with their own set of dependencies is a problem. As long as Tokio developers' expertise and testing culture go into Prost, it is not a big deal to have multiple packages. Similarly different components of the Tokio itself can be different crates, as long as they are built and tested together, them being separate dependencies is GOOD.

Now to use Prost with a gRPC server, I need a different project: tonic which comes from a different vendor: Hyperium. This is an increased supply chain risk that we need to vet. They use Prost. They also use the "h2" crate. Now, I need to vet the code quality and the testing cultute of multiple different organizations.

I have a firm belief that the actual People >>> code, tooling, companies and even licensing. If a project doesn't have (or retain) visionary and experienced developers who can instill good culture, it will ship shit code. So vetting organizations >> vetting indiviual libraries.