[tialaramex]

With C++ it's hilarious because the C++ community is so allergic to proper dependency management and also so desperate for stuff from third party libraries that the committee spends large amounts of its time basically doing dependency management for the community by baking in large features you'd ordinarily take as a dependency into the mandatory standard library.

I'm sure I'll miss some, but IIRC C++ 26 is getting the entire BLAS, two distinct delayed reclamation systems and all of the accompanying infrastructure, new container types, and a very complicated universal system of units.

All of these things are cool, but it's doubtful whether any of them could make sense in a standard library, however for C++ programers that's the easiest way to use them...

It's bedlam in there and of course the same C++ programmers who claim to be "worried" that maybe somebody hid something awful in Rust's crates.io are magically unconcerned that copy-pasting tens of millions of lines of untested code from a third party into absolutely every C++ program to be written in the future could be a bad idea.

[zahlman]

> copy-pasting tens of millions of lines of untested code from a third party into absolutely every C++ program to be written in the future could be a bad idea.

Is it really that bad? (By my count, as a point of reference, the Python 3.13 standard library is just under 900k lines for the .py files.)

[blub]

If something is in the standard library, then it’s written and vetted by the standard library provider, not by a random third party like you make it sound.

With Rust, it’s literally a random third party.

[simonask]

Maintainers of all open source standard libraries are effectively "random third parties". With heavily used ecosystem dependencies (such as Tokio, but also swaths of small libraries, such as `futures` or `regex`), the number of people who have looked at the code and battle-tested it is also huge.

On crates.io, a good heuristic is to look at two numbers: the number of dependents and the number of downloads. If both are high, it's _probably_ fine. Otherwise, I'll manually audit the code.

That's not a complete solution, especially not if you're worried about this from a security perspective, but it's a good approximation if you're worried about the general quality of your dependencies.

[blub]

People are paid to work on standard libraries and there’s a whole process behind developing and releasing this software.

Tokio on the other hand is the library whose maintainer decided to download a binary blob during build: https://github.com/tokio-rs/prost/issues/562 https://github.com/tokio-rs/prost/issues/575

Good luck catching such issues across dozens of crates.

[simonask]

The issue you linked is a perfect example in support of my argument. Lots of people noticed the problem, and it was quickly rectified.

[shwouchk]

what other “quality” is there to worry about besides security?

[simonask]

Stability, correctness, test coverage, performance.

You can lump anything under "security" for particular use cases, but what's the point of words then.

[tialaramex]

> it’s written and vetted by the standard library provider, not by a random third party

All three modern C++ standard libraries are of course Free Software. They are respectively the GNU libstdc++, Clang's libc++ and the Microsoft STL. Because it's a huge sprawling library, you quickly leave the expertise of the paid maintainers and you're into code that some volunteer wrote for them and says it's good. Sounds like random third parties to me.

Now, I'm sure that Stephan T. Lavavej (the Microsoft employee who looks after the STL, yes, nominative determinism) is a smart and attentive maintainer, and so if you provide a contribution with a function named "_Upload_admin_creds_to_drop_box" he's not going to apply that but equally Stephen isn't inhumanly good, so subtle tricks might well get past him. Similar thoughts apply to the GNU and Clang maintainers who don't have funny names.

[blub]

One Stephan T. Lavavej is worth more than 1000 random github rustaceans, some of which will be bots, AIs, rank amateurs, bought or North Korean spies. Any of the libraries has one or more Stephans.

Having paid maintainers, code review, test suites, strict contribution guidelines, etc is state of the art for open source software that some transitive crate dependency can only dream to achieve.

[kibwen]

> With Rust, it’s literally a random third party.

No, tons of the foundational Rust crates that show up in every dependency tree are first-party crates provided by the Rust project itself.