So I've got a foot in each camp, I think you're just using different languages - you guys mean different things with the same words.

You can't claim he doesn't know what he's talking about with a single point he may have gotten run, the makes a tonne of valid points, especially around the existing problems of C++ that this library doesn't help with.

In addition to that, he's not wrong about this library from a user perspective. I can't use this. I wrote something very similar back in 2016 - at the time it served my needs but now it's hilariously outdated.

To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.

Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude.

And that number tends to reduce even more when the ecosystem matures.

It may be fewer but it still doesn't feel good when cargo pulls in hundreds of deps for a seemingly simple application. But maybe it seems simple because of all the deps...

Agreed, but that's the reason why it keeps being a huge problem in JS while other languages only have an eventual small trouble.

But also, almost all of those deps on all simple apps are the same in Rust. They are the same for a large part in JS too, but it's for a smaller part than on most languages.

This; even Golang for medium sized projects (NNCP, Yggdrasil) have about 8-10 deps on average. Rust's dependency chain it's unmanageable for a distro manager.

From Golang the Rust dependency size it's closer to NPM than Go.

Supply chain attacks are available to every language and framework that uses dependencies or modules you don’t control.

Yea I’m a big fan of rust but it does feel uncomfortable to see my dependency blowing up to the hundreds when I build

There is build.rs, proc macros are unsandboxed, and lastly you install the binary so that you can run it. Even if the build and install were fully sandboxed, the binary could still do malicious stuff if ran.

Even without post-install script, a malicious payload could be hiding in some function and just wait until the developer invokes `cargo run`. Not that many people audit the crates they pull into their projects.

Yeah no shit, if you download malicious code from the internet and run it on your computer you will get pwned. No matter if it’s from a package manager a zip file or a submodule.

However the current npm vulns used a post install script.

I maintain that NPM malware use postinstall scripts just because they exist and are convenient. Had NPM not had postinstall scripts, the malware would have used a different mechanism and been almost exactly as effective.

It has build.rs that will run as soon as you compile the dependency. That's not the same thing but pretty close to a post install script: it's very likely to run.

They have build.rs (https://doc.rust-lang.org/cargo/reference/build-scripts.html)

It has build.rs, which has essentially the same problems.

Is it? It's kind of the heart of the matter - just because something is common doesn't mean it's acceptable. The difference is that in our society we've all agreed the sacrificing is no longer acceptable.