An "unsafe" set of calls from Rust to C are still no less unsafe than calling C from other C or from C++. The biggest difference is in programmer expectation, which is why it's so unfortunate when a "safe" wrapper has bugs. Rust can't fix bugs in the underlying C library either, of course. That's one place where Mozilla's recent foray into FFI via compiling to WASM then compiling the WASM to native code is very interesting to me.
But making that unsafe Rust block safe to call from safe Rust isn't the most trivial of things to do. Conforming to all the safety requirements is still a thing to deal with, otherwise you contaminate all your safe Rust code.
It's not an unreasonable burden for what you get in return, but it is still a burden.
That burden exists if you're calling into it from C, it's just implicit. At least Rust gives you the tools to write safe wrappers. Once you've done that consumers of your library don't have to tiptoe around the possibility of unsafe behavior.
> That burden exists if you're calling into it from C, it's just implicit.
That point is absolutely crucial. It's not just implicit, it's also often undocumented. Recently, I tried to call LLVM's ORC2 JIT functions from two threads concurrently – an interface which was designed to be thread-safe [1]. And yet, actually doing that resulted in non-deterministic crashes and failed assertions. Guess it wasn't thread-safe after all... None of the types or function prototypes gave any indication that they weren't thread-safe, not to mention the documentation. And that's an extremely popular open-source project! The reality for most other C++ code looks even worse.
This is my experience as well. I feel like a lot of people who are experts at C++ and have been using it for literal decades now really fail to appreciate how hard it is to learn C++ in 2022. They have all of this stuff in their heads already and it's easy, so the vast amount of undocumented knowledge is invisible to them.
