Could Microsoft switch from its use of C, C++, and C# to other languages? A recent blog post from the Microsoft Security Response Center (MSRC) suggested that it might well be looking at alternatives, with the aim of reducing the risks to its code. As Gavin Thomas, the principal security engineering manager at MSRC, noted that one of the main causes of the bugs in Microsoft code reported to the MSRC is memory corruption, bugs that let memory be overwritten or access what should be protected memory.

Keeping memory safe

Memory safety has been a significant issue for a long time, but the statistical work done by MSRC shows the issue is not going away. You’ve got lots of tools to help write secure code, from Microsoft’s own Secure Development Lifecycle, to using newer memory-safe languages like C#. But those approaches have their trade-offs: The code they produce is slower and works at a higher level than C++.

That’s not a problem for customer-facing code. There’s no perceptual difference between a C++-develoepd user experience and one built in C#. But a system level, the code used to build operating systems and device drivers, there’s a big difference. Processor cycles matter when you’re working at a systems level, and as Thomas points out in his blog post, unprotected languages like C++ and C are really the only tools that historically work at that level.

It’s clear that the memory-safe approaches used by higher-level languages don’t work at a system level. Many of the problems that plagued Microsoft’s abortive Longhorn project were caused by trying to build an entire OS on the .NET platform. So how can we bring memory safety to the foundations of system development?

Introducing Rust

The answer comes with a new generation of systems programming languages like Go and Rust, languages that have the memory-safe designs of .Net with the speed of C and C++. Microsoft is already using Go extensively in Azure, because it’s the language Kubernetes is written in. But these approaches haven’t made their way to Windows yet, where C++ is still the systems programming king.

In his blog post, Thomas makes an argument for using Mozilla’s Rust as a safe systems language for Windows. It’s an interesting suggestion, and one that’s already got one big proof-point in its favor: The language designer Mozilla is already using it in its latest web browser releases, where it powers Mozilla’s current and next-generation rendering engines. Other big Rust users include the JavaScript module repository NPM, Dropbox, and Oracle. Even Microsoft is already using it, with Rust code in some of its Azure IoT Edge tools.

Setting up a Windows Rust development environment

The obvious place to start with Rust development is Visual Studio Code. In its Extensions marketplace you can find several extensions that install the Rust Language Server and that come with full language support as well as tools for building your Rust apps from Visual Studio Code. I’ve been using the official Rust extension from the Rust language team. Other tools provide support for code snippets to kickstart development, as well as additional debugging and test tools. There are even tools for building documentation for your code. It’s worth installing the Rust extension pack as part of your Visual Studio Code Ruse environment, as this adds additional tooling for working with Rust’s own development tools.

You first need to install the Rust compiler and the Cargo package manager. The official Rust installation site will detect the version of Windows you’re using and provide the appropriate download. There are even instructions for installing Rust on Windows Subsystem for Linux (WSL), if you’re using WSL as part of a Unix development tool chain. Running the Rustup installer downloads the language components and sets the Windows PATH. You do get the option of customizing the install, but in practice it’s best to accept the defaults.

Understanding Rust and memory safety

If you programmed C or C++, the transition to Rust is relatively easy. There’s a lot of similarity between the languages, though it’s Rust’s concept of ownership that makes it memory-safe. Ownership lets Rust manage the scope of variables, allowing them to be valid only while in scope. If they’re not being used, they’re not in memory. Some variables are literals, immutable values hard-coded into your code. But more complex variable types can request memory when they’re set, a process that in other many languages requires you to explicitly allocate memory and then free it when the variable or object is no longer needed. Rust automates this, handling memory usage as part of its scope management.

The team at Mozilla that created Rust has thought deeply about memory safety and the trade-offs that can happen in a safe environment. The result is a language that’s both safe and fast, with tools that manage both memory stacks and heaps. Assigning a value to a function changes its ownership, moving it from one scope to another; a similar process manages values that are returned from a function call.

Ownership is a complex concept, but it’s an important one. It protects memory and it lets only the functions that own a value change it, even when you’re using a reference to a variable. Because Rust treats a reference as borrowing the variable, trying to modify it will only generate an error, unless you declare it mutable.

The future of Rust in Windows

It’s important to remember that Rust is still a young language, and much of what you take for granted in Windows development isn’t there. There’s no direct integration with Win32 or other core Windows SDKs, and you won’t find any support for Windows GUI tools without installing additional libraries. However, that’s not as much of an issue as you might think: Rust, like Go, is a systems programming language. It’s a low-level tool, fast and safe. That makes it ideal for building code that manipulates your data, crunching numbers, and processing arrays. Instead of using C++ routines where you’re working with large amounts of memory, use Rust instead, reducing the risk associated with memory corruption.

If you do want to develop GUI applications in Rust, you have the option of using one of several UI libraries. Perhaps the easiest to use is Kiss-ui, which supports both Windows and Linux GUI development, with Win32 API access as well as support for the cross-platform GTK. Other libraries add deeper Win32 API support.

Even if Microsoft doesn’t end up supporting Rust directly, there’s plenty of community support. While assembling a full tool chain may still be a matter of choosing the various elements you need and using tools like Rustup to install them, the arrival of Visual Studio Code extensions and extension packs seems set to simplify the process. Regular updates show that this is very much a live project, with the Rust team and a host of third-party contributors at work on it.

The underlying principle of using memory-safe languages is an important one, and it’s certainly good to see the folk at MSRC addressing the problem. Until there’s an official release of a memory-safe low-level systems programming language, it’s certainly well worth giving Rust a once-over. If Microsoft does choose it, you’re going to be well ahead of the game.

Outside of Windows, Rust is a key language for WebAssembly development and should help deliver much more powerful web applications in the upcoming Chromium-powered release of Edge—another reason to give it a careful look.