The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting.

While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of being used for userspace "system" utilities in the same vein as the Rob Pike's C-like Alef on Plan 9). At the same time, much of the public rationale given for Go was obviously to avoid the pitfalls of using C++ at Google-like scales (e.g. an aversion to junior-dev footguns and a fanatical focus on fast compilation), which implies that they saw some potential for replacing C++, though they later acknowledged that very little of Go's growth appeared to be coming from C++ programmers (see https://commandcenter.blogspot.com/2012/06/less-is-exponenti... : "Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.").

Meanwhile, given that Mozilla intended to write a browser engine in Rust, old versions of Rust absolutely intended to replace C++. Like D and Go, ancient pre-0.1 Rust was willing to impose a runtime by default in order to guarantee memory safety (originally intending for both green threads and a garbage collector to be baked into the language), until years of experimentation proved that its static checks were capable of providing memory safety without a runtime, which is the pivotal moment in Rust history (actually a series of pivotal moments, but let me be romantic). Nowadays, rather than market itself as a C++ replacement exclusively, Rust tends to position itself outside of the traditional spectrum of languages as simply a zero-overhead memory-safe systems language. While it's still true Rust competes with C++, is inspired by C++, and can be used to replace C++ (e.g. its usage at Dropbox and in Firefox), Rust also intends to compete directly with C, e.g. for system utilities (e.g. ripgrep), reusable low-level libraries (e.g. librsvg), and extending high-level languages (e.g. Helix).