Ending up compromised by a problem in tokio, Pin semantics, actix or all the necessary ffi bindings is no different than, say, a C program being compromised by a vulnerability in OpenSSL or libcurl.
A very significant number of memory issues in C stemmed from issues in such single high-profile dependency, so one should not undermine the threat of a bit of unsafe code in the corner of a library.
Rust is better.
It's very much human nature to trace the line in the sand juuuuuust right behind one's heels though, depicting everyone behind as bad and everyone ahead as zealots.
Rust is definitely better, hands down, but insisting on thinking code that interacts with unsafe blocks can be "safe by default" is a dangerously wrong mindset which also makes unsafe blocks proliferate without the necessary caution as the problem seem "contained". Anyone remember the actix unsafe saga?
But even though a program with unsafe blocks (read: all rust programs) are by definition not memory safe - calling a language memory safe on current platforms can to some extend even be considered a misnomer - the assistance provided by rust by default certainly helps make such programs much safer.
That's very different from environments where all code must be correct no matter what. But the impact of bugs isn't what changes.
Everybody already knows Rust has unsafe blocks and C FFI. It is not invulnerable to those problems, Rust just makes it very clear where those problems may appear, and if you are smart, you will place most of your code outside of those regions.
Looks like Rust is much safer on practice than what I expected.