After a long break, it’s finally time to write about Rust again. It’s been a while since my last Rust-related article.
Today’s topic is simple and very popular: replacing C/C++ with Rust. This discussion has been around for years, roughly the last 5 to 10 years, and it doesn’t seem to be going away anytime soon.
So why not take a short break from the hype and calmly think about what would actually happen if we decided to replace C/C++ with Rust?
This article is an attempt to explore that scenario realistically.
Demand for Rust Developers
If we decide to switch to a new programming language, one thing is obvious:
the demand for developers proficient in that language will increase steadily.
However, the number of developers who are truly skilled in Rust is far lower than the number of experienced C/C++ developers.
This creates a serious market imbalance. As you can probably guess, demand and labor supply wouldn’t match.
Rust developers would become extremely valuable and would likely earn more than many other programmers. But corporations don’t optimize for developer happiness; they optimize for profit. From a financial perspective, a large-scale switch from C/C++ to Rust simply isn’t very realistic.
Let’s Replace It with Rust Anyway
Now let’s assume the impossible: the market demand is fulfilled.
What a great day! Rust developers are everywhere, ready to replace old, rusty, ugly C/C++ codebases with shiny new Rust code.
They start coding with confidence, replacing millions of lines of code; until they realize something feels… off.
They would need to rewrite billions of lines of existing code.
At this point, companies gather again for another meeting. After 30 minutes, a decision is made:
Stop converting C/C++ code into Rust immediately.
Developers are shocked.
“What do you mean?” they ask.
The manager replies slowly:
Spending massive amounts of money to rewrite something that already works in C/C++ is not desirable.
Yes, Rust’s safety guarantees and memory model are impressive but are they worth billions in rewriting costs?
And another uncomfortable question appears:
Why do we suddenly need memory safety when the product is already stable and running in production?
The developers stop.
Another Idea
Then, a Rust developer steps forward with a new suggestion:
What if we keep maintaining our existing C/C++ products, but build new features using Rust?
The manager nods quietly and walks back to his office for yet another meeting.
After some time, he returns and announces the decision:
According to our new strategy, upcoming products will be built using Rust. Existing C/C++ products will continue to be maintained.
A happy ending for everyone.
Conclusion
So what was the point of this little story?
Simply this: rewriting everything in Rust is neither practical nor profitable right now and there’s no real need for it.
This situation isn’t unique. PHP, for example, still dominates large parts of the web despite its well-known downsides.
C and C++ are deeply entrenched in the industry. There are far more developers proficient in C/C++ than in Rust, and that matters.
Many critical industry software systems are still written in C/C++. In game development alone:
- Unity uses C#
- Godot uses C#
- Unreal Engine uses C++
But do you know what language these engines themselves are written in?
C/C++.
Do you really think these companies will willingly rewrite entire engine codebases just to make Rust fans happy?
Don’t dream.
Rust is an excellent tool, and many companies are adopting it but mostly for new products or specific components, not full rewrites.
Some companies (for example, Discord) have replaced parts of their systems with Rust. But even they didn’t rewrite everything. They selectively used Rust to improve performance and reliability where it made sense.
So yes, learn Rust.
But don’t learn it with the expectation that it will replace C/C++ developers anytime soon.
In the foreseeable future, that outcome doesn’t look very likely.
