Post #4333760

@chandlerc@hachyderm.io ok now that i’ve properly watched the talk i have to give huge kudos to josh for being extremely open about the obvious comparisons that anyone would make to rust, while making it to 87/91 minutes before i felt literally any urge to go “now hold on”. not serious and not your fault, a random line just ran into some Historical Political Baggage which is a fun story I now have an excuse to share :p The statement of “unsafe rust is MORE unsafe than c++” was a big talking point for years which slowly transformed from “reasonable question we’d ask ourselves” to “extremely disingenuous talking point you’d get from someone who’s trying to justify dismissing rust wholesale” (to be clear I don’t think you’re doing that at all). So like it’s definitely a legitimate concern that the existence of pervasive high-level assumptions about pointer aliasing and validity could in theory result in rust code being a big ticking time bomb where one small error in unsafe code creates a huge disaster. And certainly we do turn on several fancy noalias optimizations in llvm (although we don’t do TBAA so we’re also less aggressive in some places), and certainly that occasionally goes awry. However over the years the empirical results I’ve observed have been that UB in Rust is often more contained. In particular there’s a high chance of UB quickly causing a panic/abort because there are so many random stray bounds checks and other assertions that it’s hard for execution to go rogue for long. A weird semi-accidental defense in depth. Like for a long time Firefox thought there was some really evil UB in Rust’s HashMap but it turned out that there were just a lot of HashMaps and so any stray memory corruption bug from anywhere in the codebase (i.e. C++) had a pretty good chance of hitting a HashMap… and corrupting memory owned by Rust very quickly resulted in a crash instead of further corruption. So the crash stats were just stuffed to the gills with “oh my god we segfaulted in HashMap”!