> No flame sit. It is either safe or not. Safer doesn't qualify as safe.
I agree and I often have to try to make this clear to proponents of "modern" C++/Go.
> Your query searches for type unsafeties.
His query searches for all unsoundness in Rust (including both type- and memory unsoundness). It does not search for unsafeties. Unsoundness can enable unsafety in code written in save Rust. However, unsoundness is fixable w/o redesigning the language (though may be very hard in practice) and usually doesn't cause significant breakage when fixed (in Rust at least). Unsafety in code enabled by fixing unsoundness often disappears when the unoundness is fixed but will result in a compiler error or -lint when the unsoundness is fixed if it doesn't disappear. Unsafety in the language is not fixable w/o major redesign and ecosystem wide breakage. It should be noted that most remaining unsoundness in rustc is suspected to have very low impact in practice and are very hard to fix but they are being steadily fixed.
> A third query would be for concurrency unsafety: deadlock. All three unsafeties are builtin by design. There's no way to deny it. But they still do repeat the same lies again and again.
Deadlocks are theoretically impossible to eliminate in any Turing complete language. In Rust there are often ways to prove your program doesn't contain any deadlocks but indeed some academic research languages (mostly dealing with effect types) makes this easier in more cases. At least in Rust a deadlock results in the lack of stuff happening that you would've preferred happen (which is bad enough), not in UB like in C++ (which is considerably worse).
Memory leaks in Rust are a similar situation to deadlocks although admittedly authors of unsafe Rust need to take some care to ensure it remains similar and not a way that worse memory safety issue could occur. The Rust designers wanted to make it very clear that they consider memory leaks bad but not part of Rust's memory safety guarantees and even went so far as to add a safe function to std that leaks memory (i.e. not as a side-effect, leaking memory is what it is for).
On this note. No language can ever be save in all respects. But save doesn't mean no bugs. It means you have explicit guarantees and enforced contracts. Save rust explicitly guarantees concurrency safety except that deadlocks can occur and the compiler enforces the guarantee unless an unsoundness bug causes the compiler to fail in its explicit contract to enforce it. Similar with memory safety, which is guaranteed (and enforced except sometimes in the precence of unsoundness bugs) but the guarantees explicitly exclude memory leaks. That still leaves a lot less to worry about than in "modern" C++ where absolutely no concurrency- or memory safety is in any way guaranteed nor enforced. Rust is all about eliminating all compromises it can and where the cost/benefit ratio makes sense but to still be pragmatic when and where appropriate.
> Stack overflows being memory safe you can tell your grandma or upper management. Problem was rust was once memory safe, but they ripped out the GC. Now it's just better than C++, but not better than Java or really safe languages. Overhype rarely reflects well on a community.
Stack overflows are memory safe in Rust. Rust's safety guarantees don't say stack overflows will not occur only that they would not cause specific issues if they do occur (like double free or UAF or ...). Again. Sometimes it is possible to prove they cannot occur but in general this is an impossible problem to solve in any Turing complete language.
EDIT: Also: GC's don't prevent stack overflows either. Therefore I don't get your point.