[okanat]

> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides.

This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. There are millions of small libraries everywhere too!

Their CMakeLists files or conan packages also execute random commands and in the case of supply chain compromise they are as vulnerable as Rust. Actually CMake is so complicated that one can hide an exploit a bit better than build.rs.

I don't think it is a good thing either way and both toolchains should implement ways to limit execution and isolate code generation. For the packages we also need to see stronger ownership and signing guarantees. Maybe even a domain-based validation system with TXT-keys against takeovers. Allowing random people to just register and typosquat packages is not a good idea.

[physicsguy]

That's not really true at all though, even in very complex software it's pretty rare to have more than ~10 external dependencies in a C++ project. People tend to roll their own a lot more, partly because dependency management is a lot more painful and fragmented. Boost is effectively an extended standard library, as is abseil, but the language has got much better at incorporating back features since C++ 2011, but even so, the dependencies tend to be slow moving and fairly stable.

[tobias12345]

True, you have few external dependencies... but you have random code thrown into your repository in the form of vendored 3rd party libraries, header only libraries, and bits and pieces copied from somewhere. Of course you also get huge kitchen-sink libraries that do everything, so you only need to add one library and have semi-decent functionality for everything you might need. At least those usually have people working on maintaining their usually pretty huge dependency tree -- those they know of. They have the same problems knowing their true dependency trees as everybody else in the eco system.

I have not yet looked at any C++ code base > 1 milliom lines where I did not find at least 3 copies of zlib. Often just the compression or decompression function copy and pasted into a random file. Which version? No idea. Was it patched? Likely. Is there any documentation on how to update this? Absolutely not. Was it easy to find? No, some specialists even rename the functions so that users linking to the system zlib do not get into symbol conflicts. I have heared way to often that it is so much simpler to just copy a class over from abseil, or whatever other library than to depend on it.

Sure, you do not see dependencies, the functionality those provide are still there somewhere though -- either hidden away or in the form of reimplementations. You just do not know... and what you do not know about you can not maintain.

[armitron]

I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.

[okanat]

https://archlinux.org/packages/extra/x86_64/blender/

https://archlinux.org/packages/extra/x86_64/apache/

They look no different than your usual Rust crate. And their full flattened dependency trees already exceeds hundreds of packages.

C/C++ libraries have much more complex build systems with many optional features shipped inside the library. Just think of curl and how many protocols it supports.

Rust's build system, however, is extremely simplistic and limited. So to have things like multiple backends for rendering, parsing, serializing etc. you have to split your library into multiple crates due to limitations Cargo impose on you. So the full equivalent of curl will be 20+ individual crates.

I think the hundreds of dependencies is overblown due to this effect. I maintain my argument. C and C++ projects are just as complex and vulnerable. CMake and fully binary distribution via Linux package managers just hide their complexity.

[dwattttt]

I haven't seen hundreds of dependencies in C projects either. But I _have_ seen on the scale of 1s to 10s of libraries and algorithms vendored in (sometimes just a header or 5).

It's also an indirect risk, but I've seen C projects reimplement things that would be a dependency in Rust, and introduce subtle (or not subtle) bugs.

[pjmlp]

Because most of them depend on UNIX being there in first place, aka all of POSIX, alongside Khronos APIs.

Additionally, most C libraries tend to come via UNIX package managers directly, and then consumed via CMake, pkg-config or what not.

I do agree Rust dependency trees are a problem, for security, and always compiling everything from source.