Re:Dashmap: Fast concurrent HashMap for Rust
by nickez on Friday March 27, 2020 @06:56AM
(#22701835)
I think you missed parent's point. There are constructs that the current compiler can't prove is correct and to write such code you need unsafe. It is often not about a trade-off between speed/safety.
Re:Dashmap: Fast concurrent HashMap for Rust
by Jonhoo on Friday March 27, 2020 @08:20AM
(#22702258)
I actually gave a talk about exactly this a few weeks back that may be relevant: https://youtube.com/watch?v=QAz-maaH0KM
Re:Dashmap: Fast concurrent HashMap for Rust
by asdf-asdf-asdf on Friday March 27, 2020 @08:25AM
(#22702289)
oh, i see what you mean. yes, i did somehow miss the "You can't build everything in safe Rust - certain things _require_ the use of unsafe." part of the argument.
i did talk about it in my other comment here: https://news.ycombinator.com/item?id=22701550
Re:Dashmap: Fast concurrent HashMap for Rust
by leshow on Friday March 27, 2020 @10:03AM
(#22702885)
You obviously don't understand, unsafe isn't always optional. You literally can't do some things without it. If you tried to build a Vec from scratch without unsafe for example (or using code that uses unsafe) you would fail.
Data structures are a perfect place for judicious use of unsafe.
i wrote: "i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes."
you wrote: "Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down."
it's the same thing. the difference is that you look at it from the glass-half-full point of view (it's good that must-be-verified-by-a-person blocks are limited here), and i do from the other end (it's bad that these blocks are necessary).