The pervasive mention of "C/C++", as if C and C++ were the same language with the same failure modes, soured the whole thing for me, for reasons:
In modern C++, C bugbears are just not a problem that demands much attention; I had one (1) memory mistake in five years, caught in initial testing.
There are still plenty of bugs, of course, but they are overwhelmingly specification bugs: code is doing what was asked for, but what was asked for was wrong.
Babysitting the borrow checker steals attention from preventing those actually very common problems. In effect, the borrow checker has also consumed all the time then spent tracking down and fixing the bugs it prevented avoiding, and all the time spent adapting to bad interfaces it caused that more or less worked.
Attention is, by far, the scarcest resource every programmer manages. Anything that burns attention without adequate return is actively harmful. Coding at a higher level, using powerful, safe libraries trusted not to cost too much, is how C++ programmers get the safety that Rust coders grind out on the borrow checker. C++ has many, many features, not in Rust, meant specifically to help capture powerful semantics in libraries that raise the level of coders' attention.
The large and still growing suite of such features, and the powerful libraries written using them, account for the almost exclusive use of C++ in all the highest-paid, most demanding applications in fintech, medtech, HPC, CAE, telecom, and aerospace. Rust will never be able to call those libraries.
Still, Rust is the only extant language plausibly gunning for C++'s role. It starts with the advantage of leaving behind many of C++'s worst backward-compatibility boat anchors, but its focus on low-level safety features detracts attention from the high-level coding support that makes them decreasingly relevant. Rust is adding features and users at a rapid rate, but C++ picks up, easily, many more new users in each week than the total headcount of Rust programmers working in that week, and will continue. To be remembered in ten years, Rust will need to become useful to many, many more programmers than it is now winning over (HN buzz notwithstanding).
Gunning for C++ is a losing strategy. Planning to coexist with C++ will have better results. Rust is an overwhelmingly better language, on every axis, than C, Go, Java, C#, ObjC, Visual Basic, Delphi, and COBOL, all being coded today mostly by people who will and often should never use C++. Every conversion from those is a big net gain for the world. Rust will pick up few C coders, despite that this would produce the greatest benefit to society, just because almost all who might jump already did. But the rest are wide open.
Promoting memory safety is not the way to win those, either because they have it (at enormous cost) or don't value it. To win those coders, Rust needs to take memory safety as given, and promote fun, performance, and a future.
Java won big in 1995 by offering Microsoft sharecroppers a way out. Rust could be the way out for a new generation, if only it can raise its sights from C's too familiar failings.