Looking at things from a more general standpoint, there are many examples of Rust being used in production already. Admittedly as previously stated where the need for functional safety assessments aren't stringent nor is the need for a robust set of commercial grade tools. That's still a solid chunk of the market.
I think a lot of open source projects that land in commercial products don't have the same degree of quality tooling associated with commercial counterparts. That doesn't stop those products from succeeding.
On the basis of examples such as Microsoft's disclosure of the use of Rust in the Windows 10 kernel's IPC COM bridge, Google's use of Rust in OpenTitan and a couple of others that I'll need to dig up (but evidently do exist in the public domain), I would say that in the general case Rust doesn't need a 10-20 year horizon to work in the same general spaces as C. Time will tell how true that ends up being but the trend is quite clear to me (and I was a Rust nay-sayer for quite a while before actually doing a reasonably sized OS kernel port that made me see the value).
Excuse the slight meandering but you come across as the sort of person who would appreciate some of these points. The significant value add that Rust brings is compile time memory safety - something that C/C++ simply don't have or likely to in a scale-deployable manner. The security and safety stick is hitting so hard now that a lot of the traditional arguments against an upstart programming language option are now seemingly more palatable to a lot of shops. There's a lot more to Rust then just the memory safety - I often lament about how the other bits don't get enough attention. The threading is top-notch, the expressiveness as a result of functional patterns is addictive (I find myself using Rust programs as alternatives to everyday Python/Ruby scripting - 'tis true!), the generics are lean and not overwrought as C++, the composability using traits is a good middle-ground to insane class hierarchies in C++. I could go on!
Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge. When C and C++ are massaged to get to a similar space, they likely won't be the same languages anymore anyway.
Speaking about performance parity as a related aside: As an admittedly crude but IMO representative example Rust is already at par or better than C and/or C++ for the only truly open and idiomatically comparable suite I could find - drum-roll...micro-benchmarks - specifically The Benchmarks Game (results publically available). Now I concede that micro-benchmarks don't represent reality but they are what _every_ compiler engineer uses first to sanitise their port (and even what a lot of processor architects use in their RTL simulations - because that's often all they can run to completion at KHz rates) and therefore have good representative value in the first order.
More representative macro-level use-case comparisons are harder but there are sufficiently many examples of higher level frameworks (web servers etc) that showcase Rust's safety and performance. Those didn't require commercial grade tooling and a fair number are being used in production today.
About ISA convergence - and talking about the low perf deep embedded end - which is where the compiler tooling is lacking - Arm has been providing zero dollar cost licenses for the past 2 years now. See Arm DesignStart Eval and DesignStart Pro. You can do Cortex-M0 and Cortex-M3 evals at 0 USD upfront cost and have pretty much the same royalty arrangement as you would with any alternative. Heck at 75K USD you can even do a Cortex-A5. Such initiatives are likely only the beginning so the trend is quite likely going to be convergence. That's all speculation I admit but the argument is a lot easier to buttress with concrete examples now.
I would urge folks to give Rust a go. Wait - that sounded like a pun! :)