Hello everyone, and welcome to the Sprkl Expert Talk. This time, we’ll discuss Rust and its relationship with Node.js regarding performance. In our expert talks, we host a prominent developer in each episode and explore topics that would bring value to the community.
I’m Raz, a software engineer at Sprkl Personal Observability, and I’m the person who came up with those questions.
Sprkl is a Personal Observability platform that provides personalized feedback on your code changes while coding in the IDE. Sprkl helps ship correct and efficient code while spending less time on debugging, code review, and frustrating rework. Powered by OpenTelemetry, Sprkl instruments every code change and analyzes it upon execution. Check out Sprkl on VS Code marketplace.
This time we interviewed Alberto Esposito, software engineer, consultant, and Node.js enthusiast. The interview with Alberto was very insightful for me, and I hope you’ll also gain some value from it 🙂
My name is Alberto, I’m a 34-year-old engineer from Italy. My background is in applied math, focusing on computational statistics and numerical simulations. I’ve worked in the tech sector for almost 15 years, starting as a consultant right out of high school and then moving across all of Europe.
I recently decided to take a sabbatical year to write a next-generation database, yottastore, and hopefully turn it into an open-source startup. I also work a lot on io_uring, one of the most critical emerging technologies in the Linux space, a revolution for backend developers.
With Rust, instead, I will probably spend more time writing code that will satisfy the borrow checker, but in exchange, I will have implicit proof that my code is reasonably safe and readable.
As a project maintainer, it’s easier to review and accept a pull request made in Rust; as a newcomer, it’s easier to understand what the code is doing thus enabling faster onboarding.
The recent introduction of the Linux kernel proves that Rust is tackling some deep pain points in the lives of engineers, helping us to be more productive and write correct code.
I think it’s a fair picture of Rust and its ecosystem: smaller than others at the moment but very active with a more significant amount of collaboration, enabled by the guarantees made by the language.
Rust and Node.js are a match made in heaven, thanks to WASM. It represents a natural development path for backend and full-stack engineers who want to write better code without wasting years of experience in the Node.js ecosystem.
A much better approach could be to write a `no_std` implementation that could then run in browsers and backend runtimes thanks to WASM.
I personally think that developers should avoid NAPI as much as possible and prefer WASM. Portability is one of the reasons, but the build system’s complexity and some unfortunate design choices drove me away, an opinion shared by Ryan Dahl, who decided to follow a different approach with its rewrite of Node.js in Rust, Deno.
But WASM has its limits: it’s a sandboxed API, so it cannot access the system. To do that you need a NAPI bridge.
For example, we can take the implementation of HTTP/3 for Nodejs, which was started more than 4 years ago by heavyweights like James Snell and Matteo Collina; after multiple scope cuts, the issue is still pending due to complexities in the NAPI or security bugs. It’s clear to me how Rust could have been of help here.
A different approach I took to implement QUIC in node.js was to bridge an equivalent to the Syscall module via NAPI to do the heavy lifting in Rust using `io_uring`. This way, you have a portable, self-contained WASM module, with strong safety guarantees thanks to Rust, in an architecture more similar to micro kernels than the monolith Node.js has become.
As a manager, I want to use Typescript as much as possible: it’s easier to hire developers who use TS, and their salaries are almost 30% less than Rust developers. Infrastructure is much cheaper than engineers, and most of the time, I’m pressed for fast deliveries rather than safe code.
As an engineer, I want to use Rust: it’s better for my career and makes my future life easier by allowing me to trust the existing codebase.
I think it’s essential to strike the right balance, starting with a pure Node.js implementation and then starting to migrate hot paths or critical code to WASM+Rust. Writing pure Rust should be reserved for mission-critical services, where performance is paramount, like a proxy server or a database.
Enjoy your reading 7 Min Read