You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking.
The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating new C and C++ codebases to alleviate the problem for the future.
Exactly, it's a chicken and egg problem. C++ has tons of libraries, while Rust has barely any. Rust can use external C bindings, but not C++ ones yet. I think if they solve the issue of using C++ libraries from within Rust, the transition will be much easier, and meanwhile more native Rust libraries will be created.
Yes, in the cases where the operating system is done in C++.
The C ABI is the operating system ABI and it is only ubiquitous in operating systems done in C. Other operating systems use whatever ABI the system offers.
How many Rust libraries are there for various tasks? What IDE supports Rust? What tutorials, books and conferences exist that teach and distribute the state of the art in development techniques? What example projects have been build in it to demonstrate its feasibility for large projects? What tools support Rust (continuous integration, code formatting/checking, build tools, ...)?
Well using make as an example of anything good is... let's say 'suspicious'. There is more to tooling than make and git (note that I deliberately omitted version control from my list)
The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating new C and C++ codebases to alleviate the problem for the future.