This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.

It's possible to migrate C to Rust function by function, not sure if anyone has figured out something similar for C++ yet though:

https://github.com/carols10cents/rust-out-your-c-talk

There is also https://github.com/immunant/c2rust

Rust is not equal to C++, not even language wise and certainly not from a tool / pipeline / libraries / knowledge side.

When you have legacy code, with millions line of code you just don't swap for something else for the sake of it might be better.

Adding a new language in a medium / large company is not an easy task.

I think Rust is a good contender for C++ "replacement" on the long term but it's a really difficult task and you need proper planning.

> for the sake of it might be better.

There are a billion Windows computers on the planet. Each time we have a buffer overrun which gives attackers access or lets them exfiltrate user data, real people are at risk. At risk of ID theft, of money theft, of scammers, of crypolockers, of extortion and blackmail, of company collapse and job loss, of stolen business secrets, of fines, and of wasted time. Each time we have an urgent patch, tens of thousands of IT people around the world have to hurry to patch/bodge/remediate/mitigate/educate systems with little warning and little testing, dragged away from whatever else they were doing.

Microsoft have proven they can't do this competently in C++. Are we not long past the "might be better to have tools which check" speculation, and far into "definitely definitely definitely is better" by now?

If not by now, what will it take to convince you?

(I'm not saying "Definitely Rust", but something - Microsoft make implementations of C++, T-SQL, C#, F#, JS/TypeScript, VB.Net, and employ many top Haskell people at Microsoft Research, and various other languages, they aren't inexperienced at languages).

it's a really difficult task and you need proper planning.

Then they should hire good developers and plan properly? They are one of the richest companies on the planet who make some of the most popular programming languages and tools on the planet. They're not a poor-me charity case.

Microsoft is fully aware it is reached the tipping point.

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

Worth pointing out that MS has made extensive investments into making their C++ code bases safe and secure in the last ~twenty years, yet they still regularly have these problems. If Microsoft cannot handle the problem, few organizations would have the resources to.

Also see the recent slew of security issues on OpenBSD, which is developed by what many consider some of the most skilled and careful C programmers.

Because one issue doesn't mean hurry we need to switch language. Especially not on the OS side where unsafe will be used and has not yet to be proven that is safer than C/C++ with various tools.

If you think that's possible why no-one is actually doing it?

There are mainstream efforts to do the legwork to allow Linux kernel modules to be written in Rust and a fair few core system libraries (the most obvious example being librsvg) and applications have undergone Rust rewrites. And of course there's Redox OS which a full OS entirely written in Rust, and it only contains a few hundred lines of unsafe code (which, given how Rust works is the only really key code that needs to be audited for memory safety).

The reason that more things aren't yet written in Rust is because these things take time, and there is lots of inertia to switching languages for established projects (one big roadblock to such rewrites is that maintainers need to be familiar enough with Rust).

> yet to be proven that is safer than C/C++ with various tools.

What "various tools"? Buffer overruns were old-hat decades ago. Impossible in Pascal in 1970, impossible in ALGOL-60 years before that. If the C/C++ tools to protect against buffer overruns in 2020 are worse than the technology of sixty years ago, how much longer do you suggest we wait?

> Because one issue

This isn't the first buffer overrun issue. This isn't the first buffer overrun issue in 2020. PHP has had a buffer overflow which could leak data or crash. IBM DB2 has had a buffer overflow which could allow an attacker to gain privileges. macOS and all iPad/WatchOS and iTunes for Windows have had buffer overruns leading to arbitrary code execution. Samsung Galaxy S10 has. QEMU has. pppd has. SQUID has. CA Nimsoft has arbitrary code execution buffer overflow. PHP Multibyte string handling has. Emerson OpenEnterprise SCADA, libmysofa, OpenJPG, mRuby, libMing, Cisco Unified Contact Center, Honor smartphones, QEMU iSCSI handling, Intel Graphics Drivers, Adobe Reader arbitrary code execution (Again!)

just look https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer

and that's only the CVE disclosed ones.

> If you think that's possible why no-one is actually doing it?

It's cheaper and more profitable not to bother.

I don't agree with you that C++ is superior to Rust