Rust: Memory Safety, High Performance, Pick any Two

In the industry, the vast majority of code is written using a handful of programming languages. These can broadly be divided into high-level languages (Java, C#, JavaScript) and low-level languages (C, C++). Languages in the former category introduce high-level abstractions that enhance programmer productivity, such as automated memory management and run-time introspection. The latter category of languages is typically used for high-performance or low-latency applications, as they give the programmer full control.

This control comes with the responsibility to make programs safe and secure, which is not easy: Microsoft recently published a study showing that 70% of all its patches addressed memory safety bugs. In a nutshell, these memory safety bugs are caused by multiple entities in a program taking ownership over the same piece of memory. Disagreements on the lifecycle, size or shape of a piece of memory can result in arbitrary code execution and from there, a full system compromise.

One of the programming languages thas has recently gained traction in the industry is Rust. In Rust, ownership of memory is explicit: a piece of memory may only have one owner at any given time. This means that the memory safety issues from above are by definition impossible: the Rust compiler will signal a compile error. Explicit ownership also improves programmers’ ability to reason about multi-threaded programs, where concurrent access to shared data is a constant source of headaches. The net benefit is that programmers can deliver software with fewer bugs, quicker.

Rust code compiles to native code, which means that it does not need to be hosted in a virtual machine like Java or C#. This is a financial and scale benefit for cloud applications, as Rust applications have very little overhead in terms of memory or startup time. Rust libraries can also be loaded and used alongside other native libraries, which enables gradual adoption. Finally, Rust code can be compiled to WebAssembly such that small kernels of high-performance code can be written in Rust and made available to web applications written in JavaScript or other WebAssembly-capable runtimes. This then becomes an avenue for reusing code between the client and server or enabling novel web applications.

Despite all the advantages of Rust, few people are advocating for rewriting existing codebases in Rust or mandating it for all new projects. The programming languages mentioned at the beginning of this blog post still have their place and their vast ecosystems of libraries. Rust is not going to displace these any time soon. Instead we expect that the native libraries underneath will become “oxidized”, either gradually or as rewrites. The Android operating system is a good example of this philosophy. In Android 13, 21% of all new native code was written in Rust — most notably media components which need to decode untrusted inputs at high speeds. The Firecracker project (mentioned earlier here) is exclusively written in Rust for the same purpose. Microsoft is similarly using Rust for new Windows low-level components and rewriting existing components as needed.

Since Rust is supported by the major platforms and the toolchain is mature, the best way to get started as a company is use cases where Rust’s strengths are needed: code that is security-critical, performance-critical, or both.