5 ms·
I'm no stranger to unsafe code but in my professional work, I avoid it almost any cost. In my experience the common denominator among average engineers is an av
by akiselev 6y ago
I'm no stranger to unsafe code but in my professional work, I avoid it almost any cost. In my experience the common denominator among average engineers is an aversion to the kind of processes that derisk unsafe code, where average == "I can reliably find at least two engineers at this skill level within the next few months with competitive but not FAANG-level salaries". This is why Rust is so successful in the first place: it's a low level language disguised as a high level language (or the way around, depending on your perspective) where you don't have to worry about fuzzing or vagrant. That `unsafe` is avoided like the plague is a great feature of the Rust ecosystem and IMO an achievement in its own right.
I've actually found the reverse problem to be even more detrimental: people coming from high level languages like Python are getting tripped up because they try to go too low level to make up for tradeoffs they no longer have to make. Rust makes it painfully obvious when wrapping a shared value in a Rc+RefCell/Arc+Mutex or cloning so it seems like an antipattern to newbies. Even though the majority of them are coming from languages where everything is implicitly reference counted and performance is abysmal, they worry about incrementing an atomic integer or acquiring a lock in a program that will only ever run on x64. I can't imagine what they'd come up with using `unsafe` if the community didn't literally refer to it as the dark arts.
- iudqnolq 6y agoI've found I constantly want to build off of an existing c or c++ library, so I need unsafe. I'm much less experienced than the people's code I'm using, and I'm generally fine with "Rust protects against me, if the lib authors screwed up then bad things happen".
- akiselev 6y agoAbsolutely. I don't base my choice of libraries solely on `unsafe` but at work the number of people who will review internal unsafe code is a fraction the number of people that would review even a moderately popular open source library.
- kibwen 6y agoIMO, using `unsafe` in order to do FFI is of a fundamentally different character than pure-Rust `unsafe`. To the compiler they're the same thing ("I can't verify this, be careful"), but to a reader/auditor the former is fairly reasonable ("I can see why it might be pragmatic to not have to rewrite this entire C program in Rust"), whereas the latter should raise eyebrows ("why, exactly, does this need to be `unsafe`?"). (That said, you obviously still have to be cautious when doing FFI.)
- iudqnolq 6y agoI thought the same, but it seems to me the logical conclusion is to mark "I've added no unsoundness compared to if you were using the library I'm binding to" as safe, and add in the docs homepage a general vibe of how sound the bound library is. When I suggested this on the Rust Reddit enough people thought this was a fundamental insult to the principles of what Rust means to them I decided not to do this.
- timidger 6y agoDo you have a link to that discussion?
- nicoburns 6y agohttps://www.reddit.com/r/rust/comments/mxiufr/when_soundness_isnt_worth_it/ https://www.reddit.com/r/rust/comments/mxiufr/when_soundness... I was one of the people who commented on that post. My point was basically that "you need to uphold invariants in order for this to be sound" is exactly what `unsafe` means in Rust. So if you're wrapping a library that doesn't guarantee safety then you should mark it as unsafe (and there's nothing wrong with that). Rust library users will typically assume that they can do absolutely whatever they want with a safe interface and they cannot possibly cause memory safety issues, undefined behaviour, etc. A large part of the benefit of Rust is not even having to think about that. So it's important that libraries continue to stick to this convention.
- mlindner 6y ago
- nyanpasu64 6y agoThere are tools to automatically generate "safe" C++-Rust bindings (the intent being to restrict unsafety to trusting C++ code to be sound, without the risk of screwing up the bindings): https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx and https://cxx.rs/ https://cxx.rs/. However, creating bindings without typing out `unsafe` was a controversial issue, discussed at https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate/ https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate... . Also there are tools to automatically parse C++ headers and turn them into cxx bindings: https://github.com/google/autocxx https://github.com/google/autocxx and https://docs.rs/autocxx/ https://docs.rs/autocxx/
- iudqnolq 6y agoWhen you use that sort of thing you pretty much always need to handwrite some bits as well.
- paulryanrogers 6y agoDid you mean Valgrind or is there a Vagrant besides the VM manager?
- akiselev 6y agoYes, I got my V* tools mixed up
- mlindner 6y agoOveruse of "Rc+RefCell/Arc+Mutex" IS something of an antipattern though. In C programming you try and avoid doing too much of that kind of thing as you can get stuck in "undefined behavior" whereas in Rust you'll instead end up coding yourself into a circular dependency or some other construct that will never compile. So I agree that you should avoid using them other than where needed in Rust.
- styluss 6y agoDefinitely this is very common. I've seen static variables with Arc+Mutex and initialised with lazy_static when they're only used once in a single thread, in multiple jobs.