Microsoft: Why We Used Programming Language Rust Over Go For WebAssembly On Kubernetes App

Microsoft has detailed one more area where it's engineers are using the Mozilla-created Rust programming language, a new project from a team at Azure to test WebAssembly modules in Kubernetes. 

Microsoft is already experimenting with Rust to rewrite low-level components of Windows originally written in C and C++, and is also looking to Rust's memory-safety features to create a new language for 'safe infrastructure programming' under Project Verona. 

DeisLabs, an Azure incubator for creating Kubernetes tools, has also used Rust to build Krustlet, a 'kubelet' than lets developers run multiple WebAssembly modules (Wasm) in Kubernetes, the dominant open-source tool for managing Docker containers. 

Kubernetes was created by Google and written mostly in Google's Go programming language. 

"While there have been many stories about using Rust for systems-level programming, you don't often hear stories about cloud software or Kubernetes software being written in Rust. So, we wanted to explain why we made the choice we did," writes Taylor Thomas, a senior software engineer at DeisLabs, Azure. 

The Krustlet project, which emerged earlier this month, is "highly experimental", with DeisLabs warning that "you should use it in production at your own risk".  

WebAssembly, an open standard supported by all major browsers, has primarily been used for creating powerful web applications that run in the browser. The main reason DeisLabs chose Rust for Krustlet is because Rust has native build support for compiled Wasm binaries or modules. 

But Microsoft is forging ahead with Rust-based Krustlet to help developers push WebAssembly code outside the browser, in support of Mozilla's release last year of the WebAssembly System Interface (WASI) so that compilers can target a single interface rather than multiple operating systems.

Developers can use Krustlet to test-drive WebAssembly modules in Kubernetes alongside containers within "constrained and security-conscious environments" where containers typically are challenged.   

DeisLabs developers also chose Rust because of its "strong safety and security guarantees". Despite early troubles with Rust that put a drag on productivity they realized they could save time downstream by not exposing null pointers, thread safety issues, and other bugs. And they argue they were able to significantly reduce the efficiency gap between programming in Rust compared with Go.  

"For the first week or so, we lost much of our time to learning how borrows worked. After about two weeks, we were back up to 50% efficiency compared to us writing in Go. After a month, we all were comfortable enough that we were back up to full efficiency (in terms of how much code we could write)," writes Thomas. 

"However, we noticed that we gained productivity in the sense that we didn't spend as much time manually checking specific conditions, like null pointers, or not having to debug as many problems."

On the issue of security versus missing features in Rust, Thomas highlights a recently discovered race condition in Helm, which was written in Go and was not picked up by the race checker for Go. But, he says, the bug would definitely have been caught by the Rust compiler.  

"Even though we sometimes miss having a garbage collector so we don't have to worry about cloning, borrowing, ownership, etc., the pain we have avoided because of the Rust compiler's strict rules is incalculable," said Thomas. 

"For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place."

Ralph Squillace, a principal program manager on Azure application platform upstream, said, "Using Rust to build Kubernetes components was a wonderful experience compared to Go, and it should be much more widely adopted for Kubernetes work."

But Thomas said Rust still had obvious problems, including the length of time required to learn it. 

"One of the biggest ones to point out is that async runtimes are still a bit unclear," noted Thomas. He also said the learning curve was difficult, which chimes with top obstacles to Rust adoption revealed in Rustlang's most recent survey of developers. 

"It takes several weeks of hard effort learning how to code properly in Rust before the learning curve levels out. However, that hard effort up front pays off in dividends due to the aforementioned safety features," said Thomas.  

"We also noticed that once developers are over that initial curve, they are able to contribute to code just as easily as with any other language. Just be aware that there will be some initial pain."

Nonetheless, Microsoft's Azure engineers intend to continue using Rust for projects where it's a good fit and "highly recommend" it for upcoming cloud projects. 

More on programming language Rust

• Programming language Rust's adoption problem: Developers reveal why more aren't using it  
  
  
• Google programming language scorecard: How C, C++, Dart, Rust, Go rate for Fuchsia
• Developers love Rust programming language: Here's why
• Microsoft: We're creating a new Rust-like programming language for secure coding
• Programming languages: Kotlin rises fastest but JavaScript lures millions more developers
• Microsoft opens up Rust-inspired Project Verona programming language on GitHub
• Brave defies Google's moves to cripple ad-blocking with new 69x faster Rust engine