We have solid data on how much Rust improves safety, while “too many” dependencies seems rather arbitrary. They tend to be high quality and better vetted/tested than bespoke code or copy-pasted hpp headers
> They tend to be high quality and better vetted/tested
I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust?
> “too many” dependencies seems rather arbitrary
I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many".
> I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust?
Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library.
> I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many".
Then don't use them?
Your concerns appear to boil down to 'bad software exists'. Which... yeah. It does. Not sure what you want us to say. It's an intrinsic characteristic of open source / free software, and it's not like C/C++ is somehow under-represented (or Rust over-represented) in dodgy software.
There's plenty of closed ecosystems you can stick to if you don't trust yourself not to use dodgy dependencies (though I think this is a very strange concern to have).
> Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library.
Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro.
Somehow it feels like Rust does not go really well with distros (because it pushes for static linking).
> Your concerns appear to boil down to 'bad software exists'.
I was reacting to someone generalizing on C/C++ code, saying that "people dramatically overestimate it". I feel like it's nice to have some memory safety brought by Rust, but I find it a bit hypocritical to criticize the security of C/C++ code if Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads. Because that's a big security issue IMO.
Sure, you can do it right with Rust. But you can also write good code with C/C++.
> Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro.
You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in distro PMs uses distro dependencies like any other package. Equally, as you note, the reverse exists. None of this tells us very much about Rust or C/C++ as languages.
> Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads
'Tend to' is doing a lot of heavy lifting in that sentence, and doesn't seem to be based on very much more than 'I saw it a few times'. Well, I've seen my share of nightmarish C++ dependency trees. Is that a good argument against C++? Not really.
You're picking up on real issues - unnecessary and untrusted dependencies - except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good, which is where a rational argument seems to collapse into vibes. On the whole, there's a lot more C++ projects out there guilty of this than Rust projects.
> Sure, you can do it right with Rust. But you can also write good code with C/C++.
You can hammer a nail with a broom, but that doesn't make it the best tool for the job. The safety advantages of Rust can't just be hand-waved away. C is a fine programming language when safety is less of an issue. If you're writing a Nintendo emulator, sure, C, why not. If you're writing business logic that handles health data, maybe not.
> Rust software that's distributed in distro PMs uses distro dependencies like any other package.
I haven't found a single Rust package that depends on a shared Rust library coming from the system package manager. Do you have an example of that? Genuinely interested in seeing how it looks. Many people tell me that Rust "doesn't support shared libraries", which seems odd to me. But I have never seen one, so...
> except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good
I don't think that, maybe I did not express myself correctly. I was answering to a comment that, to me, sounded like "C/C++ bad and Rust good", by saying that I also see issues in Rust (namely with the dependency management).
I like Rust-the-language. What I don't like, to be honest, is how Rust people seem to believe that static linking is the solution to all their problems.
Last I checked Rust itself does not have a stable ABI, so there are effectively no "shared Rust libraries" outside of static linking / compiling from source.
But they can and do simply use C's ABI when dynamic linking, because that is stable. Rust-to-Rust libraries generally don't bother with this because Cargo exists and that trivializes "build from source" and is far more configurable and optimizable and compile-time-provable, but it's used any time Rust uses C-compatible stuff or vise versa and that's quite common.
I am not reading anything saying that there exists C/C++ code. I read code and make my own opinion.
Most code is bad, but that's true for Rust as well. The memory safety does not magically make code good. BTW Rust is not the only language that has memory safety, by far.
