Lup Yuen Lee 李立源 @lupyuen@qoto.org

@lupyuen Having skimmed that paper as someone who's lurked on /r/rust/ and the Rust RFCs since before version 1.0, my impression is that the paper's focus is misguided:

1. I didn't see any evidence of them addressing the question of whether Rust affects the *number* of CVEs filed per amount of code, which seems like an obvious important thing to consider in a situation like this.

2. It comes across as if they're oblivious to the fact that other safe languages, like Python, have FFI support, like the ctypes module, and are calling out Rust as uniquely flawed in how the safe and unsafe code interact.

3. When they're classifying the vulnerabilities, it feels like they're oblivious to the fact that they are re-discovering the already well-known implications of constructs necessary for C FFI. (Had they approached it from a "does the real-world of Rust match the expectations for these constructs?" angle, it wouldn't bother me, but what they wrote feels like it lacks that self-awareness.)

4. I'm not a programming language theorist but, given the level of theoretical discourse that shows up in Rust RFCs, the kinds of ideas that show up in Rust team member blog posts, and the kinds of tooling, both experimental and production-ready, which get announced in /r/rust/, their recommendations for mitigating the risk feel so simple that I'd be surprised if they weren't already on the list of things that have already occurred to the relevant people and either are "easier said than done" or have non-obvious fatal flaws.

All in all, it just has an air of "People who know far less than they think they do acting with un-earned confidence".

(In fact, it feels vaguely reminiscent of the parts of the Unix Hater's Handbook that, yes, are a problem with Unix... but nobody else has managed to put anything better into practice.)