It's a frustrating situation. I take pride in crafting tools that make other OSS maintainers' lives easier, so I can't fault them for abandoning those tools when a vocal "deps for me but not for thee" minority raises such a fuss that they stop using those tools — but it really takes the joy out it.
...and it's doubly frustrating because these folks are working against the eventual outcome they ostensibly want: the inclusion of safe transmutation APIs in the standard library. That design effort really benefits from having enthusiastic users of crates like bytemuck and zerocopy.
Yes, and I would much rather have one file with unsafe code, which is run through the best tooling standards we have, carefully audited, used in many other crates, rather than fifty different crates each with their own bespoke implementation of parts of zerocopy.
100% agreed, and having seen the amount of care, skill, thought, and effort that is put into zerocopy, I'd 100x prefer having a zerocopy dependency over any other unsafe code.
zerocopy's unsafe code has at least 100x more than the median amount of unsafe-vetting in Rust packages.
I don't get why the concept of enforcing safety invariants on contained sections of code is so untenable for many people. It sounds like the moment you type `unsafe` you get an instant privilege escalation RCE when the idea is that you just confine it to small areas that are easy to reason about. 🤷
The “no unsafe” thesis of some Rustaceans is weird because it’s contrary to Rust’s own ethos. Rust seeks to modularize safety, with careful auditing for the unsafe bits that are necessary
Comments
zerocopy's unsafe code has at least 100x more than the median amount of unsafe-vetting in Rust packages.