So I didn't believe it before, but it's starting to seem more plausible.
Of course, it'll take a very long time. There's a lot of C code out there. :D
It may be the case that some people use Rust but without Rust jobs, there will be no pool of experienced developers to later draw on.
Most of the world are things other than real systems programming. C++/C#/Java/Golang are likely better choices for this than either C or Rust.
But a C-like language is necessary. Rust may be (very slowly) displacing C for systems programming.
As you mention, it takes awhile for the pool of experienced developers to show up.
Anecdote: My company is a nearly 100% Rust shop and we have never made it a job requirement.
Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).
It's already the case that people are using "logic add-ons" for additional rust static analysis, so one wonders exactly why is it generally speaking that borrow checking itself must occur at the compilation step.
Trivially, one could create an annotation layer on top of zig or c that exactly replicates the rust syntax and performance borrow checking in the same way. It wouldn't be exactly the same because there isn't RAII but you can make correct inferences about what is happening in the body of the functions.
Zig is getting an absolutely enormous boost from the fact that it is a self-contained C ecosystem that can cooperate with others. Zig has tripped into a very powerful niche--a lot of people LOATHE the build systems of the C/C++ world. If Zig gains very much more traction there, it's going to be extremely hard to dislodge.
I suspect that there are FAR more users of "Zig as C build system" than there are of "Zig as a language".
It is my fondest hope that the Linux folks will finally beat the cargo out of Rust.
But cargo already isn’t in Rust. There are AFAIK no cargo-specific concepts that have leaked into Rust, the language. It is very straightforward to build Rust code without using cargo, for example with a makefile.
The reason other tools are slow to add support for rust is because cargo is so ubiquitous in the rust ecosystem that there is little point (I’d estimate that >99% of Rust code is built using Cargo), and not because of any technical impossibility.