Why Rust? It's the safe choice.
At Matic Robots, we're building an intelligent robot with advanced hardware and software features. One of the things that helps is writing our code in Rust. There are a lot of things that influence the choice of programming language and other tools, so we'd like to share a few of the reasons that Rust works for us.
A Better Robot
Let's start by discussing why using Rust leads directly to better products.
We're putting all of the robot's intelligence into the robot itself, rather than running in the cloud. This means we need to deliver a lot of functionality with our limited compute resources. With Rust we get good performance and reliable concurrency without having to pay the costs of garbage collection or interpreted bytecode.
Another reason Rust works well for us is that correctness and safety checks don't require a performance tradeoff. Traditional verification tools (e.g. sanitizers) slow down the running code, and that will change the behavior of a robot that has to make real-time decisions. Rust's memory and thread-safety protections have no runtime overhead, so every build is fully protected. This makes our robots more reliable.
Our robot contains a lot of hardware: motors, actuators, pumps, sensors, cameras, microphones, plus embedded CPUs, I/O, onboard storage, and AI accelerators. Our software needs to manage all of that complexity, and every one of those parts can misbehave in interesting ways. Rust's FFI capabilities and strong error-handling semantics make this difficult task a lot easier. And every year new hardware improvements come along-- using Rust improves our development speed, so we're able to adapt to new hardware rapidly.
Finally, we want to set a good example for security and privacy. Networked consumer devices have a terrible reputation, and it's far too common for unsafe code to be exposed on the network. Using Rust for critical tasks prevents many common security bugs, and encourages robust error handling. This helps us harden our software and protect private data.
Benefits for the Team
There's another side to Rust, too: it makes developers more effective. If we can get more done in less time, with fewer mistakes, that contributes to our ability to make a better robot.
We don't spend time chasing memory safety bugs or concurrency errors, because the compiler has guard rails that push back when code tries to do something dangerous. It's easy to make changes quickly, because the compiler will prevent entire categories of errors. In other languages, this "push back" can be delayed a long time (until static analysis runs, or runtime safety checks fire, or customers report bugs). With Rust we can catch most of these bugs almost instantly.
A computer vision engineer mentioned to me recently that they haven't seen a segfault in more than a year. It took a moment to realize how shocking that would have been to me in a previous role as a C++ developer. After a few years using Rust, we've mostly forgotten what it's like to deal with crashes due to bad pointers.
There are long-term benefits, too. Rust's type-focused style and firm boundaries improve the long-term manageability of code. Refactoring can be done fearlessly, and the compiler safety checks are robust enough that the refactoring is often done the moment the code compiles.
Code written in other languages often depends on subtle invariants that may not be easy to express. Memory and thread safety mechanisms can require extreme care to maintain correctness. In a large-scale project, productivity can suffer if new team members are afraid to touch the code for fear of breaking things. Rust can convey a lot of meaning in the type system, making it easier to understand invariants and maintain code over its life cycle.
It's fun to learn new things, and Rust is a good teacher! When coding in Rust, the language encourages awareness of the details: errors and fallibility; shared data and mutability; algorithms and performance. While this can be viewed as an up-front cost due to the learning curve, it's also a form of continuing education. No matter which language we use in the future, those are valuable lessons that make us better at our jobs. Open source Rust projects also set a high bar for documentation, modularity, and test coverage; consumers of Rust code are constantly exposed to these best practices, and quality expectations are contagious.
Ship It!
Did we take a risk by using Rust? Are we spending our "innovation tokens" recklessly? In our experience, Rust is the safe choice, and it's hard to imagine using anything else. We are able to build things in less time, with less risk, and have more fun doing it. Developers can be fearlessly productive, because there is a lower risk of bugs that cost months of developer time.
While our experience may be specific to building consumer robots, a lot of it could apply more generally to other types of software engineering. Many projects face similar challenges with security, performance, and maintainability. We think that in the near future a lot of engineering teams will discover that they can build better products in less time using Rust, and teams using older tools should consider whether their project could benefit from an upgrade.