"We're saying goodbye to C++ once and for all," Microsoft initiates the biggest "demolition" in code history: Windows and Azure will be rewritten in Rust.

Microsoft is driving a long - term project that could reshape the entire history of software engineering: by the end of 2030, completely eliminate C and C++ code from its core codebase and fully migrate to the Rust language. This goal not only involves key infrastructures such as Windows and Azure but also means a systematic reconstruction of one of the world's largest commercial code assets.

1  A Microsoft engineer posts that C/C++ will be completely phased out by 2030

This goal is not a speculation from the outside world but a strategic vision publicly expressed by the core engineering leaders within Microsoft.

Recently, Galen Hunt, a Distinguished Engineer at Microsoft, posted a recruitment message on LinkedIn, presenting this ambitious plan clearly to the public for the first time.

According to his LinkedIn profile, Hunt has long been engaged in research and engineering practice in system software and operating systems. Currently, his research focus is on introducing large language models (LLMs) into the field of system software to solve long - standing complex engineering problems.

During his time at Microsoft, he founded and led the development team of Azure Sphere. Azure Sphere is an end - to - end security platform launched by Microsoft for the Internet of Things (IoT) and embedded devices, aiming to enable any device manufacturer to build highly secure devices. This platform systematically covers the "seven core attributes of highly secure devices" proposed by Microsoft and has become one of the important infrastructures in Microsoft's device security field.

Previously, he was one of the core leaders during the startup phase of the New Experiences and Technologies group (MSR NExT) at Microsoft Research, responsible for managing the operating system technology group. Even earlier, he led the operating system and distributed systems research team at the Microsoft Research Redmond Lab and was deeply involved in the forward - looking research of Microsoft's underlying system technology for a long time.

An important direction in his research and engineering work is to explore the boundary and trade - off between the hypervisor and the operating system kernel. Around this issue, he led the Drawbridge project, attempting to build a new computing system architecture. From 2012 to 2013, he spent a year deploying Drawbridge in real - world services on the Azure platform. This technology was later used to port Microsoft SQL Service to the Linux platform.

"My goal is to eliminate every line of C and C++ code from Microsoft's codebase by 2030."

This statement comes from Galen Hunt himself.

For a company with decades of history, a codebase of hundreds of millions of lines, and C/C++ deeply embedded in operating systems, databases, compilers, virtualization, security, and cloud infrastructure, this is not a regular technology upgrade but a system - level, organizational - level, and tool - chain - level engineering revolution. The full translation of the post is as follows:

There is currently a vacancy for an IC5 Principal Software Engineer position on my team. The work location is in Redmond, and on - site work is required.

My goal is to eliminate all C and C++ code at Microsoft by 2030. Our strategy is to integrate artificial intelligence and algorithmic technologies to rewrite Microsoft's largest codebase. Our core vision is to achieve "one engineer can handle one million lines of code in one month."

To complete this unprecedented task, we have built a powerful code - processing infrastructure: the algorithmic infrastructure can create scalable graphs on massive source code, and the artificial intelligence processing facility enables us to use AI agents for large - scale code transformation under the guidance of algorithms. The core of this infrastructure has been widely used in areas such as code understanding.

The Principal Software Engineer we are recruiting this time will help us upgrade the infrastructure to achieve the key goal of migrating Microsoft's core C/C++ systems to the Rust language. The hard requirement for this position is to have experience in Rust system - level code development (preferably with more than three years of Rust system programming experience). Candidates with experience in compiler, database, or operating system implementation are preferred. Although compiler development experience is not mandatory, candidates should be willing to learn skills in this field within the team.

Our team adheres to a growth mindset. The team members have diverse backgrounds, comprehensive skills, and unique perspectives. We are not afraid of taking risks, are good at collaborating for win - win results, and are always committed to creating value for internal and external customers. In the ever - changing field of AI tools, we deeply understand that diversity and a growth mindset are the keys to success.

Our team belongs to the "Future of Scalable Software Engineering" project group of the EngHorizons organization under Microsoft's CoreAI. Our core mission is to help Microsoft and its customers eliminate technical debt at scale by building advanced capabilities. We develop cutting - edge tools and technologies with internal customers and partners and collaborate with various product teams to promote these innovative achievements to Microsoft and the entire industry.

From an organizational structure perspective, Hunt's team belongs to the Engineering Horizons department under Microsoft's CoreAI system, and the project is called "Future of Scalable Software Engineering." This positioning is not a research and development team for a specific product line but more like an organization for incubating future software engineering capabilities. Its goal is not limited to the migration of a single system but aims to build general capabilities that can be promoted within Microsoft and even to external customers.

2  Why migrate?

In fact, Hunt's public statement this time is also regarded as a continuation of the previous statements by Microsoft's senior management. The earliest signal can be traced back to 2023. As early as 2023, Microsoft announced that it would rewrite parts of the Windows kernel using Rust.

David Weston, the vice - president of Microsoft, revealed at the Microsoft Blue Hat IL 2023 conference that Microsoft would follow Linux's example and rewrite parts of the Windows kernel code in Rust.

"We are currently in the 'crawl, walk, run' phase of Rust adoption in Windows," Weston said at the Microsoft BlueHat IL 2023 conference. "We are developing one of the most complex engineering products on the planet. But our goal is to improve security... So, in the next few weeks or months, the outside world is likely to see Windows booting with Rust code in the kernel. That would be really great. Our basic goal is to convert some of the current C++ data types to the corresponding Rust data types."

At that time, the sample code he showed explained some of the reasons for migrating the programming language: Rust code is easier to write and understand than the current C++ code. It is also more secure and reliable: For those unfamiliar with Rust, it is a modern C - like programming language loved by developers because it enforces the creation of safe, native code without the additional overhead of managed languages.

According to Weston, Microsoft has rewritten 36,000 lines of code in the Windows kernel using Rust. In addition, it has rewritten 152,000 lines of code in the DirectWrite Core library for proof - of - concept, and the performance is excellent, showing no degradation compared to the old C++ code. He also pointed out that "there is now a system call written in Rust in the Windows kernel." A system call (or syscall) is the way (in simple terms) for user - mode applications to interact with the internal functions of the kernel.

In addition to Weston, Mark Russinovich, the CTO of Microsoft Azure and a technical fellow, has also publicly stated that new kernel development should stop using C and C++. He said that all new kernel code for Windows and Azure in the future should be written in Rust. Microsoft is using large language models to promote a more automated conversion process from C and C++ to Rust to improve system security and engineering maintainability.

From a timeline perspective, Russinovich's speech was more of a directional exploration, while Hunt's recruitment and infrastructure description mark that this direction has entered the engineering implementation stage.

As for why Rust was chosen as the target language for migration, Microsoft did not elaborate in this post. However, considering the technological trends of the past few years, the motivation is not difficult to understand.

Microsoft has repeatedly pointed out in multiple security reports that the vast majority of high - risk security vulnerabilities stem from memory - safety issues, which are precisely the long - standing structural weaknesses of C/C++.

Taking 2019 as an example, Microsoft engineer Matt Miller disclosed at a security conference that in the past 12 years, about 70% of the vulnerabilities fixed by Microsoft through security updates each year were memory - safety issues.

The so - called "memory safety" refers to an application accessing the operating system's memory in a correct and standardized manner; while a "memory - safety vulnerability" refers to the behavior of software accidentally or deliberately accessing system memory beyond its bounds.

Technical personnel who often read vulnerability reports will frequently encounter the following terms: buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use - after - free, or double - free, etc. - these are essentially different manifestations of memory - safety vulnerabilities.

The high proportion of vulnerabilities is due to the fact that the Windows system, mainly written in C/C++, is based on a programming language with "memory - unsafe" characteristics. Although these languages give developers fine - grained control over memory addresses, any slight negligence in memory management code can lead to serious vulnerabilities. Attackers often use such vulnerabilities to perform dangerous intrusions such as remote code execution and privilege escalation. Currently, memory - safety vulnerabilities have become the main attack entry for hackers, and use - after - free and heap - corruption vulnerabilities are particularly favored by attackers as the most commonly exploited breakthrough points.

Rust reduces the risk of memory errors and data races systematically at the language level through its ownership model and compile - time checking mechanism, which brings direct and quantifiable security benefits for operating systems, cloud infrastructures, and virtualization platforms.

More importantly, Microsoft is facing a collection of extremely large legacy systems spanning several decades. In this context, the advantages of Rust in terms of type system, tool - chain consistency, and long - term maintenance cost are also regarded as an important way to solve the problem of technical debt. The repeated mention of "eliminating technical debt at scale" in the post by Hunt's team is a direct manifestation of this logic.

Of course, this goal is not without real - world challenges. C/C++ is deeply embedded in Microsoft's core systems, involving performance constraints, ABI compatibility, and a complex third - party ecosystem. The correctness verification, regression testing, and risk control brought about by automated rewriting are also engineering problems that cannot be avoided.

Even so, Microsoft still chose to make this goal public and set a clear timeline.

In the field of software engineering, this approach itself has sent a strong signal: with the deep integration of artificial intelligence and system engineering, legacy code assets that have long been considered "untouchable" are being re - incorporated into the scope of large - scale governance. If the vision depicted by Galen Hunt is finally realized, it will not only be a successful case of language migration but may also become a landmark event for AI's deep involvement in system - level software engineering.

2030 has not arrived yet, but the revolution around code, tools, and engineering paradigms has quietly started within Microsoft.

3  Is C++ to blame for all "memory - safety problems"? 

The technology community has had a strong reaction to Microsoft's determination to completely abandon C/C++.

Actually, two years ago, Mark Russinovich, the CTO of Microsoft Azure, publicly called for "stopping the use of C/C++ in new projects," and his remarks at that time triggered strong protests from C++ enthusiasts, many of whom were from the financial services industry.

"There is nothing wrong with C++ itself. It's just that many people using it (and other languages) actually don't know how to program," said one enthusiast.

"I admit that writing good C++ code requires good developers, and it may be much easier to find developers who can write good Rust code. However, it is entirely possible to write extremely stable, highly abstract, easy - to - maintain, and fast - running C++ code," said another enthusiast. "It's just that there aren't many people who can write good C++ code."

Russinovich's remarks even provoked a counter - argument from Bjarne Stroustrup, the "father" of C++. "We can now achieve absolute type safety and memory safety in ISO C++," Bjarne Stroustrup said in an interview with the media. Stroustrup also added: "That is, every object is used according to its defined type. This means we can eliminate the use of dangling pointers, catch out - of - range errors, and eliminate data races."

On the Reddit platform, a user created a post to discuss Mark Russinovich's decision. The user said, "As a developer who has worked with the C language for many years, I find it very hard to accept. I have mixed feelings - I understand the inevitability of the trend of the times, but I also have a deep attachment to the language history that has accompanied my career."

Some Reddit users also said that the C language has a variety of application scenarios that Rust cannot replace:

The C language has a variety of application scenarios that Rust cannot replace. The bootloader is one of them. It has very good compilation performance, and the complexity is low for an incompletely compatible compiler (the complexity of macros and some undefined behaviors is very high).

Adding more features will only make the compiler slower and consume more memory.

Rust does not have linear lifetime types to guarantee the absence of memory leaks, nor does it have non - affine types to prove the absence of undefined behaviors for a given loop - allocation pattern abstraction.

This makes Rust only have the advantage of a more powerful type system (many other languages have also fixed this, but C refuses to fix semantically incorrect code), and other languages also have this advantage.

Now, Microsoft's strategic shift has triggered extensive discussions. A Reddit user sharply retorted: "True security lies in rigorous engineering practices, not the language itself. Are there no vulnerabilities in Java projects?" He emphasized:

I'm not a Rust programmer, but I think people have over - hyped its role - it's not a panacea. For example, problems like "stack exhaustion" and "heap exhaustion," in my opinion, Rust does not provide new solutions. In fact, complex vulnerabilities such as heap exhaustion and other types need to be specifically addressed by experienced programmers in critical software development. Therefore, paying extra attention to memory vulnerabilities will not make the already complex fault - finding work more difficult.

It should be noted that I always affirm the value of static analysis. It plays an important role not only in memory - vulnerability detection but also in all development scenarios.

A developer who has worked at Microsoft for 10 years left a message under Hunt's LinkedIn post, saying that he used to think that with AI technology and the evolution of the C++ standard, there was no need to completely replace C++. Now it seems that replacement is inevitable. He said:

During my ten - year tenure at Microsoft, I mainly engaged in process memory dump analysis and later developed a post - mortem debugger for automated analysis. This experience made me deeply realize that C/C++ developers urgently need training in post - mortem debugging, which will help them better understand "what to avoid."

Over the years, the types of problems I have dealt with have been highly similar, mainly falling into three categories