[arghwhat]

Note that unsafe does not contain anything. The problem propagates to the unsuspecting caller of claimed safe code.

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.

[pierrebai]

Not being perfect does not translate to not being better. Being safe by default and having compiler-enforced safety as a top design choice is great.

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.

[arghwhat]

I did not say rust was not better. I said the statement was false, based on a misunderstanding of both the benefits of Rust and the problems of C many if which Rust is not immune to.

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.

[marcosdumay]

Yes, unsafe marks the places where your code must be correct no matter what. If it's wrong, the problems can appear anywhere.

That's very different from environments where all code must be correct no matter what. But the impact of bugs isn't what changes.