Unlike javascript, where at least it is an interpreted language people can audit, you would have to reverse engineer these binaries to figure out what they do.

If you cargo install something you get source code (unless the library packages a binary, but that's the same as if it were JS or Python or C). Rust dependencies don't become binary until the final product.

Auditing Rust binaries isn't much worse than auditing minified and uglified JS. I've done both.

EDIT:

Rust

Rust is doing pretty poorly right now.

among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

https://kerkour.com/rust-supply-chain-nightmare

I just went through the article and I don't think I agree with the assessment that "Rust is doing pretty poorly right now." It feels disingenuous, given the content of the article you linked:

826 crates match their upstream repositories at the revision they were built at. 74 crates have revisions that cannot be found in their repositories, whether due to later squash merges, rebases or revisions simply not being pushed. 73 crates do not have VCS info, either because they were built with old Cargo versions, built with --allow-dirty, or not built from a repo clone at all. 77 crates do not declare a repository in their Cargo manifest. 7 crates would match their upstream repository but for one or more symlinks being incorrectly handled. 3 crates declare repositories that do not exist. 3 crates have submodules that do not exist. 3 crates cannot be found within their repositories. 3 crates cannot be built due to cargo package errors. ... Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.