Microsoft Tier-1 Rust Language Integration

Microsoft has elevated Rust to a Tier-1 programming language, a designation that signifies its strategic importance for internal development and external ecosystem support, especially for Windows and Azure platforms. This move reflects a broader industry trend toward memory-safe languages for enhanced security.

Microsoft’s commitment to Rust aligns with its history of integrating internally vital technologies into its broader developer offerings. The company’s previous successes with C# and TypeScript demonstrate this pattern. When Microsoft prioritizes a technology internally, it inevitably becomes a significant component for anyone building applications on Windows or Azure.

Rust Joins Microsoft’s Elite Language Ranks

C#, TypeScript, and C++ have long held the distinction of being Microsoft’s Tier-1 languages. This classification implies full backing with extensive toolchains, including editors and compilers. These languages also feature deep integration with Windows and Azure through optimized SDKs and libraries, and they adhere to Microsoft’s stringent internal software development lifecycle requirements. Shipping software to billions of users necessitates this robust support infrastructure.

Rust now joins this exclusive group. This should not surprise industry observers, as Azure CTO Mark Russinovich has consistently emphasized his organization’s dedication to Rust. He specifically highlights Rust’s memory safety features as a crucial element in Microsoft’s overarching security strategy. Microsoft’s involvement as a founding member of the Rust Foundation and its substantial investments in Rust’s Windows tooling further solidify this commitment. Rust now benefits from first-class development tooling and workflows within Microsoft.

A recent Rust Foundation blog post detailed Microsoft’s ongoing efforts to integrate Rust with the existing Microsoft Visual C++ (MSVC) platform. This integration ensures seamless interoperability between Rust and C++, allowing Rust to inherit Visual C++ features as they evolve. Utilizing Visual C++ with Rust facilitates the development of low-level Windows services, from device drivers to the operating system kernel itself. This approach has already manifested in the Windows release of Coreutils, which provides Rust-based re-implementations of core UNIX commands. These Coreutils allow users to execute UNIX commands within the Windows terminal, simplifying transitions between Windows and Windows Subsystem for Linux (WSL) distributions. With Rust now a Tier-1 language, a surge in Rust-based Windows developer tooling is anticipated, providing access to low-level functionality while effectively mitigating memory leaks.

Engineering a Unified Compiler Backend for Rust

A pivotal component in delivering production-grade Windows software with Rust is a new code generation tool for rustc, Rust’s compiler. rustc is architected to support various code-generation backends beyond its default LLVM. Existing variants already function with GCC and Cranelift. Cranelift, for those unfamiliar, is the code generator developed by the Bytecode Alliance and integrated into the wasmtime framework. Developing a new code generator involves constructing a tool that interfaces with the Rust compiler’s APIs, processes its bytecode output, generates native code, and then feeds it into a chosen build pipeline.

Microsoft’s rustc_codegen_utc tooling serves precisely this purpose. It integrates with the established MSVC stack, granting Rust access to a mature, extensively tested, and proven segment of the Windows development platform without requiring any modifications to the Rust code itself; compatibility is inherently built in. This links rustc_codegen_utc directly to the backend of the Visual C++ compiler, a suite of tools orchestrated by Microsoft’s build system to manage intricate projects that combine different code and library types.

Microsoft refers to this backend internally as the Universal Tuple Compiler (UTC), though this name is not publicly visible. The actual code resides in a DLL named C2.DLL. Code is generated and delivered as .OBJ files, which are then passed to the MSVC linker to produce a binary executable. This setup allows Rust tooling to leverage decades of Microsoft’s investment in both its compilers and build tools. Eliminating the need for Microsoft to duplicate this work ensures that existing security and resilience features seamlessly extend to the Rust compiler chain. Furthermore, the resulting Rust code remains compatible with C and C++ code processed through the same backend.

Maintaining a single compiler backend significantly reduces the cost of supporting Rust. It eliminates the need for two separate compiler teams that might otherwise become out of sync with each other, as well as with Windows SDK and kernel development. This reduction in economic impact accelerates any transition and supports a probable long-term hybrid delivery model for applications combining Rust and C++. This strategy also brings Microsoft’s Rust development in line with platforms utilizing GCC and LLVM compilers, which can already use GCC and Clang backends with Rust, capitalizing on investments in Linux and macOS application development. Rust code will therefore achieve consistent interoperability across all targeted platforms.

Outlook for External Rust Developers

Currently, rustc_codegen_utc remains an internal tool, unlike other open-source Rust compiler codegen tools. Microsoft describes it as “production ready” and reports its use in over a hundred internal Rust projects, indicating significant adoption within the company. This is not the only Rust tool exclusively reserved for internal use; Microsoft’s complete Rust toolchain also includes its own builds of the core rustc compiler and standard libraries.

The internal status of rustc_codegen_utc does not mean it will remain inaccessible to external developers indefinitely. Historical precedent suggests that this and other Rust tools will likely become available with a significant update to Visual Studio or Visual Studio Code. However, predicting the exact timing is challenging. Even when internal tools are highly suitable for external use, a public release requires additional considerations, such as language servers, IntelliSense support, and full integration with the Visual Studio debugger platform. Furthermore, building code outside Microsoft’s internal environment necessitates compatibility with diverse build tools not available internally.

Discussions on Rust compiler forums reveal Microsoft’s intention to first upstream its test and backend infrastructure work into the broader Rust project. This implies that a public release may be some time away, but it also signals that open-sourcing the project is clearly on Microsoft’s agenda. The public availability of rustc_codegen_utc is crucial for broader adoption of Rust, particularly for developing third-party device drivers. This will contribute to making PCs, servers, and cloud virtual machines more stable and will significantly reduce security risks across the ecosystem.

Initiating Rust Development with VS Code

For now, Microsoft offers robust Rust tooling that integrates seamlessly with Visual Studio Code. It also provides comprehensive guidance for developing on Windows with Rust. To leverage Microsoft’s Rust language extension for VS Code, rust-analyzer, developers still require the MSVC C++ Build Tools for compiling and building code. Additionally, a Microsoft-developed Windows crate provides direct access to Windows APIs. An automated process continuously collects metadata from Windows APIs, ensuring that they remain current. Microsoft also furnishes detailed documentation explaining how Windows API calls and structures are projected into Rust.

Beginning to work with existing Rust tools now is a prudent step for developers to familiarize themselves with Windows development in this new language. This proactive approach allows them to immediately benefit from Rust’s memory safety features and understand the language’s mechanics, including necessary adjustments to their programming style. Consequently, when Microsoft eventually releases its internal tooling to the public, developers will be well-prepared to utilize it for building low-level code, such as drivers or libraries, that require interoperability with Microsoft’s own C++ components.