There's a "point of no return" when you start to struggle to hire anyone on your teams because no one knows the language and no one is willing to learn. But C++ is very far from it.

There's always someone willing to write COBOL for the right premium.

I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).

Writing C++ is easier than writing Rust. But writing safe multithreaded code in C++?

I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.

Anecdotally, my "wow, this Rust business might really go somewhere" was when I tried adding multithreading to a random tool I made (dispatching tasks to new threads).

Multithreading had not been planned or architected for, it took 30 min, included the compiler informing me I couldn't share a hashmap with those threads unsynchronised, and informing me on how to fix it.

I've had similar experience when the compiler immediately found unsynchronized state deep inside a 3rd party library I've been using. It was a 5-minute fix for what otherwise could have been mysterious unreproducible data corruption.

These days even mobile phones have multicore CPUs, so it's getting hard to find excuses for single-threaded programs.