3 ms·

I'm baffled by why this answer is downvoted. It matches my experience precisely, and articulates the proper approach for isolating `unsafe` code so that the sa

• nyanpasu64 6y ago
  My guess is that fewer people are proficient in writing Rust than know about it being memory-safe, and only a fraction of Rust programmers have studied how to write unsafe code, its (footgun-filled) potential for undefined behavior, and the task of writing safe interfaces that don't allow for UB... yet the rest of them vote on HN anyway, thinking that "safe code can't cause UB" (which is an incomplete mental model). On a related note, looking at the comments of a semi-"fluff" blog post commenting on an unsafe-Rust data race (https://news.ycombinator.com/item?id=26713037 https://news.ycombinator.com/item?id=26713037), I'm the first person across all of the Mozilla bug-tracker, Mozilla blog, and HN comments to point out that Firefox had "data races in safe code" because an unsafe block in a (module-private) "safe" function was unsound, allowing other safe code in the module to cause data races. (Maybe not the first, https://news.ycombinator.com/item?id=26714209 https://news.ycombinator.com/item?id=26714209 pointed out the 'bad pattern of "sprinkle atomics it until it works"' (though not researching it as deeply as I did) and got downvoted even though they were right in this instance.)