C++ vs Rust vs Go?

Umm... According to you, those guidelines "can be verified statically at compile time, the same kind of safeties provided by Rust can be had from C++". OTOH, according to Stroustrup et.al., right on the page you are refering to, "The sets of rules have not been thoroughly checked for completeness, consistency, or enforceability". Both are direct quotes, and no offense, but I suspect that the authors of those guidelines have better idea concerning their state...

IOW, it sounds interesting, but you seem to be seriously overselling that.

The promise "the same kind of safeties provided by Rust can be had from C++, and with less annotation effort" is vapourware until a complete set of static checking rules is published, along with an argument that enforcing those rules guarantees safety.

I'm skeptical it can be done at all. Their approach is based on requiring use of unique_ptr and shared_ptr and disallowing unchecked casts and array access, but that's nowhere near enough. Consider for example
unique_ptr<int> p;
void f1(int& foo) { p = nullptr; foo = 7; }
void f2() { f1(*p); }
The basic problem here is multiple aliases to the same data. Rust *and its libraries* were designed from the ground up to control aliasing (including features like lifetime parameters that C++ doesn't have). The last I saw of the CppCon proposal, the authors were just invoking the panacea of "alias analysis" to catch such errors without explaining how that will work. I wrote a PhD thesis on alias analysis and trust me, it's no panacea.

Even if such static checking rules and a soundness argument are eventually published, the question remains whether the subset of C++ allowed by the rules looks anything like actual C++ code. For example if the solution to the above problem is to disallow use of references, that would be crippling and I would argue that subset of C++ is not useful.

No. I don't believe they have, or will do.

Safe Rust provides memory safety even with threads, because it also provides thread safety. But outside of threading, it fixes the iterator invalidation problem. Which has caused real security flaws in Firefox. Iteration invalidation is still on the TODO list for the C++ guidelines.

It's not possible to prevent iterator invalidation without run-time checks, when you allow mutable aliases. An aliased reference to the container can invalidate the iterator.

Rust just bans mutable aliases. You can't share a mutable reference to an object (shared_ptr). Within a shared object graph, if you want mutability you have to wrap types with RefCell. It allows one, and only one, mutable reference to be created. This is a run-time check.

I mean, I'm sure there are ways to retrofit alias checking to C++. But the C++ people haven't said _anything_ about it, they're just treating shared_ptr as safe. Because it's a massive break, foreign to both C++ _and_ the widespread safe languages such as those used by their employer.

The safe languages rely on run-time checks in the iterator (garbage collection probably helps make it easier as well).

You can't just safety-check C++ iterators because the same applies to any reference.

struct A {
unique_ptr<B> b;
};

A& f(A& a1, A& a2)
{
a1->b = make_ptr(b());
return a2->b; /* returns dangling reference if &a1==&a2 */
}