It is fine, there is just not much Rust safety advantage left then. Also in C/C++ the errors do not usually occur when using a nicely defined API, but when doing the low-level gnarly stuff and getting it wrong. As said before, I think there is some advantage of Rust having a safe and unsafe subset, but is is nowhere as big as people claim it is.
The last fifty years have shown us that you can't — at least not sustainably and at scale. You can do so at one moment in time, or for smaller projects, but not in the face of large scale projects with team members changing over time.
> It is fine, there is just not much Rust safety advantage left then.
There's exactly as much as there was before though. The entire point of the Rust safety paradigm is that you can guarantee that unsafe code is confined to only where it is needed. Nobody ever promised "you will never have to write unsafe code", because that would be clearly unfeasible for the systems programming domain Rust is trying to work in.
I frankly cannot understand why people are so willing to throw the baby out with the bathwater when it comes to Rust safety. It makes no sense to me to say "my code needs to have some % unsafe, so I'll just make it 100% unsafe then" (which is effectively what one does when they use C or C++ instead). Why insist on not taking any safety gains at all when one can't have 100% gain?
The fallacy is believing that C / C++ code is 100% unsafe. Yes, Rust propaganda repeats this over and over but a good abstraction in C / C++ will also give you good safety properties. The safe Rust code over gnarly unsafe Rust code is only a little bit better than a nice C / C++ abstraction over gnarly code.
