The npm engineering team shares why Rust was the best choice for addressing CPU-bound bottlenecks

Last month, the npm engineering team in a white paper shared why they chose Rust to rewrite their authorization service. If you are not already aware, npm is the largest package manager that offers both an open source and enterprise registry. The npm registry boasts of about 1.3 billion package downloads per day.

Looking at the huge user base, it is not a surprise that the npm engineering team has to regularly keep a check on any area that causes performance problems. Though most of the network-bound operations were pretty efficient, while looking at the authorization service, the team saw a CPU-bound task that was causing a performance bottleneck. They decided to rewrite its “legacy JavaScript implementation” in Rust to make it modern and performant.

Why the npm team chose Rust?

C, C++, and Java were rejected by the team as C++ or C requires expertise in memory management and Java requires the deployment of JVM and associated libraries. They were then left with two options as the alternate programming languages: Go and Rust. To narrow down on one programming language that was best suited for their authorization service, the team rewrote the service in Node.js, Go, and Rust. The Node.js rewrite was acting as a baseline to evaluate Go or Rust.

While rewriting in Node.js took just an hour, given the team’s expertise in JavaScript, the performance was very similar to the legacy implementation. The team finished the Go rewrite in two days but ruled it out because it did not provide a good dependency management solution. “The prospect of installing dependencies globally and sharing versions across any Go project (the standard in Go at the time they performed this evaluation) was unappealing,” says the white paper.

Though the Rust rewrite took the team about a week, they were very impressed by the dependency management Rust offers. The team noted that Rust’s strategy is very much inspired by npm’s strategy. For instance, its Cargo command-line tool is similar to the npm command-line tool. All in all, the team chose Rust because not only it matched their JavaScript-inspired expectations, it also gave better developer experience. The deployment process of the new service was also pretty straightforward, and even after deployment, the team rarely encountered any operational issues.

The team also states that one of the main reasons for choosing Rust was its helpful community. “When the engineers encountered problems, the Rust community was helpful and friendly in answering questions. This enabled the team to reimplement the service and deploy the Rust version to production.”

What were the downsides of choosing Rust?

The team did find the language a little bit difficult to grasp at first. The team shared in the white paper, “The design of the language front-loads decisions about memory usage to ensure memory safety in a different way than other common programming languages.”

Rewriting the service in Rust came with an extra burden of maintaining two separate solutions for monitoring, logging, and alerting for the existing JavaScript stack and the new Rust stack. Given that it is quite a new language, Rust currently also lacks industry-standard libraries and best practices for these solutions.

Read the white paper shared by npm for more details.

Mozilla engineer shares the implications of rewriting browser internals in Rust

Mozilla shares key takeaways from the Design Tools survey

Mozilla partners with Scroll to understand consumer attitudes for an ad-free experience on the web