Is Rust Ready for Robotics in 2026?

Yes for the code you write yourself, no for the code you borrow — Rust the language is ready and the robotics ecosystem around Rust is not. The compiler, the tooling and the embedded story are settled, while drivers, planners and mapping still live in C++, reachable through ROS 2 or through a middleware like HORUS. That flips the moment your robot's value is a package somebody else wrote. The rest of this post is for a Rust developer sizing up a robotics project and for a team deciding how much of a machine to commit to Rust.

You have written Rust for long enough that the compiler stopped being an opponent, and you would like your next project to be a machine. So you go looking, and the first hour is encouraging: there are crates for serial ports, for matrices, for transforms, for talking to a few cameras. The second hour is less encouraging.

The lidar you bought has a C++ driver and a vendor SDK, and no Rust anything. The planner everybody recommends is a package in a workspace you would have to learn to build. The community bindings you found are real work by real people, and the last release note mentions a distro that is not the one on your machine. Somebody on a forum says just wrap the C++ library, and you can, and now you maintain a wrapper as well as a robot.

Meanwhile the arm on your bench does not care what language it is driven from, and neither does the person who asked when it would pick something up. The question stops being about the language and becomes about the calendar: is this ready enough that choosing it will not cost you the project?

Is Rust ready for robotics in 2026?

Yes for the code you write yourself, and no for the code you were hoping to borrow. As a language for building a robot's own software — the control loop, the state machine, the safety monitor, the firmware on the board — Rust is past the point of being a bet. The compiler is stable, the tooling is boring in the good way, cross-compiling to the boards robots use is a solved afternoon, and the embedded story is genuinely strong. As a replacement for the robotics ecosystem, Rust is not ready and will not be soon, because that ecosystem is thousands of C++ packages representing decades of work, and nobody is rewriting it. A machine whose value is your own behaviour, running on hardware you understand, is a fine Rust project today. A machine whose value is mapping, navigation and a vendor's driver is a C++ project with some Rust in it, and pretending otherwise costs months.

What does ready actually mean for a robotics language?

Ready means five separate things, and Rust scores differently on each. First, the language and compiler: is it stable, and will code you write this year still build next year? Second, the toolchain: can you cross-compile to your board, flash it, debug it and get a backtrace when something breaks in the field? Third, the libraries you need for the robot's own logic: maths, transforms, serial, network, logging. Fourth, the drivers and algorithms you were not planning to write: camera drivers, lidar drivers, mapping, planning, kinematics for your specific arm. Fifth, the people: can somebody else on the team read it, and can you hire the next person? Most arguments about whether a language is ready are really arguments about which of these five the arguer cares about. An embedded engineer answers yes because the first two are excellent. A team lead on a mobile robot answers no because the fourth is thin.

What are your actual options if you want Rust on a robot?

There are seven options, and they differ mainly in how much borrowed code sits between your Rust and the hardware. You can write a pure Rust application on Linux with no middleware. You can write embedded Rust firmware on the board itself. You can use the community ROS 2 bindings and get an ecosystem attached, at the price of following work you do not control. You can run a Rust program beside C++ ROS 2 nodes and bridge between them. You can wrap a vendor's C API and stay in Rust above it. You can pick a middleware where Rust is not a second-class citizen: HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where all three share the same shared-memory ring buffers, so messages between processes on one machine are not serialised, while ROS 2 covers similar ground with a far larger ecosystem and its own officially supported client libraries. Or you can write C++ now and revisit Rust later, which is a real answer.

What should you pick if you are a Rust developer new to robots?

Write your own code in Rust and borrow everything else in whatever language it already exists in. This is the single decision that separates Rust robotics projects that ship from ones that stall. The instinct that serves you well elsewhere serves you badly here: the shaky dependency is a camera driver representing somebody's two-year fight with a manufacturer's firmware quirks, and rewriting it buys you nothing anybody will see. So draw a line at ownership. Behaviour, safety checks, state machines, anything that encodes what your robot is for — Rust, and you will be glad in a year when the machine runs overnight without anybody restarting it. Drivers, planners, kinematics libraries, vendor SDKs — take them as they are and put a clean boundary around them. The line moves over time, and it should move slowly, one component at a time.

What robot hardware is Rust ready for today?

Rust is most ready at the two ends of the hardware range and least ready in the middle of an existing fleet. At the small end, a microcontroller driving motors with no operating system underneath is where Rust looks best: the tooling is mature, and the memory guarantees matter most where there is nowhere to log to. At the large end, a machine expected to run for days without a restart benefits from a language where a slow leak cannot quietly accumulate. The awkward middle is a single-board computer inside a robot that already has a working C++ stack and a shelf of vendor drivers. There, Rust readiness is entirely a question about your specific parts, and the check is concrete: look up whether your camera, your lidar, your motor controller and your board's peripherals have usable crates today. A mature crate for the exact part you own changes this decision more than any general argument about the language.

What if you need a robot working this quarter?

Use whatever your team is already fast in, and give Rust one part — the part that would hurt most if it failed. A quarter is not enough time to learn a borrow checker, a robotics stack and your own hardware simultaneously, and early robotics is mostly discovering how wrong your assumptions were. Rust makes each of those discoveries slower, which is exactly backwards when the discoveries are the work. That said, deadlines do not excuse everything. If the machine can hurt somebody, or if a motion must stop at a limit, that specific component is worth writing carefully in a language that will not surprise you. The failure mode to avoid is the middle: starting a broad Rust rewrite six weeks before a date, ending with half a robot in each language, and demonstrating neither. Decide the boundary in week one and leave it alone.

What if nobody on your team has written Rust before?

Then start with one bounded program and expect the first month to be slower than the estimate. Rust's learning curve is front-loaded and lands on one specific skill — deciding which part of the program owns each piece of data and how long a borrowed reference may live. Robot code happens to be a friendly place to learn it, because ownership maps onto physical things: this program owns the motor, that one owns the camera, a reading is a copy of something that already happened. What hurts a small team is not the difficulty but the breadth. Writing the driver, the transform maths, the planner and the operator interface in Rust because Rust is now the house language turns a two-month project into a year. Pick the one program where being wrong is most expensive, write that in Rust, and let the rest stay as ordinary as it likes. That usually means a Rust loop with Python above it deciding what to do next, which is the same division a learning-driven robot ends up with.

What does it look like when Rust is not ready for what you are doing?

It looks like a team spending its weeks on plumbing that has nothing to do with the robot. The signature is a stand-up where nobody mentions the machine: one person is fighting a build for the target board, another is regenerating message types after a binding update, a third is writing a wrapper for a vendor header full of templates. The robot itself has not moved in a fortnight. A second signature is the unmaintained bridge — a program written in a hurry to connect Rust to the rest of the system, which now needs a change every time either side changes. A third is subtler: the team quietly stops adding features that would need a library they cannot get in Rust, so the robot's capability is being shaped by the ecosystem rather than by the requirements. That last one is the dangerous one, because nothing looks wrong. The check is to ask what you would have built this month if the language were not a constraint.

What do teams try first when they want Rust on a robot, and why does it stall?

Most teams start by looking for the Rust version of the robotics stack, and stall when they find bindings rather than packages. The bindings are genuine work maintained by volunteers, and they do what they say — but they trail official releases, they cover part of the interface surface, and the thing you actually wanted is still C++ underneath: the mapper, the planner, the driver for the camera on your desk. The second attempt is usually to wrap that C++ library, which works and hands you a maintenance job that grows every time the library changes upstream. The third attempt, and the one that tends to hold, is to stop trying to make everything one language. Let the borrowed parts run as they were written, run your own code as a separate Rust program, and let the two exchange messages. That structure is how robots get built anyway, which is why what middleware actually does in a robot is worth understanding before settling a language strategy.

What do you give up by committing to Rust now?

You give up the largest body of working robotics code in existence, most of which is C++, and some of which you would have to wrap or reimplement. That is the big one and the rest are smaller. You give up quick experiments: changing behaviour to see what the machine does is slower when the compiler wants the ownership story coherent first, and early robotics is almost entirely that. You give up hiring ease, since the overlap between people who can read robot code and people who can read Rust is thin. You give up some vendor support, because the SDK that came with your arm was written for something else. And you take on a build story that has to work on the target board, not only on the laptop where it was written. None of this is fatal. It is an argument for being selective, which is the same conclusion the broader case for Rust on a robot reaches from a different direction.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the robot's value comes from code somebody else already wrote. A machine that must map a building and navigate to a goal is a ROS 2 project, because the mapping and navigation packages represent years of work nobody reproduces beside a day job. If the sensor you bought ships only a ROS 2 driver, that settles it, and porting a driver to keep a codebase in one language is a poor trade for almost everyone. ROS 2 also wins when the system spans several computers, when new people must be able to read the robot in their first week, and when the tooling around a running system — introspection, recording, replay — is what makes debugging possible at all. HORUS is not the answer for those projects, and choosing it there means rebuilding plumbing that could have been inherited. A Rust developer landing in one of those projects is better off writing one node in C++ than importing a toolchain nobody else can build.

Is the Rust robotics ecosystem too small to build on?

No, and here is why: the size that matters is the size of the part you cannot write yourself, and for most robots that part is smaller than it looks. Count what a machine actually needs. Serial and network communication: available and mature. Linear algebra, transforms, quaternions: available and well used. Peripheral access on common microcontrollers: strong. What is genuinely thin is the top of the stack — full mapping systems, general motion planners, drivers for specific commercial sensors — and those are exactly the components most teams should be borrowing across a process boundary rather than importing as a library. The ecosystem argument gets overstated because people compare package counts, and package counts measure the wrong thing when your robot needs four libraries and one driver. Do the inventory for your machine specifically. Write down every component you will not write yourself, then check each one.

Does Rust being ready mean you should rewrite your working robot?

Partly, but not the way you think. There is a real case for rewriting, and it is narrow: a component that crashes in ways nobody can reproduce, that runs continuously, and whose logic is small enough to hold in your head is a good candidate, because Rust removes exactly the family of bugs producing those symptoms. What is not a good candidate is a working subsystem being rewritten because the team prefers the language. Rewrites of working robot code have a specific failure pattern: the old version encoded years of small corrections for real-world behaviour — a sensor that lies near shiny surfaces, a startup order that matters, a timeout tuned after a bad week — and none of that is in the documentation, so the rewrite reintroduces every one of those bugs in a new order. If you rewrite, do it one component at a time, run both versions side by side on the same machine while you gain confidence. Do not begin with the safety layer.

How do you decide whether Rust is ready for your robot?

Make a list of every component your robot needs that you will not write yourself, and check each one for Rust support. That list is the entire decision, and it takes an afternoon. For each item there are three answers: a usable Rust crate exists, a C API exists that you can call without much ceremony, or the only option is a C++ library you would have to wrap or run as a separate process. Count them. If almost everything lands in the first two columns, Rust is ready for your robot today and the general question is irrelevant. If several land in the third, you are not choosing between languages — you are choosing between writing Rust with a process boundary between you and the borrowed code, or writing C++ and keeping it simple. Both are respectable. What is not respectable is deciding by preference and finding out in month three, which is how most of these projects go wrong.

Decide by situation rather than by preference:

• If you are writing the whole machine yourself on hardware you understand -> Rust, because the ecosystem gap does not apply to code that does not exist yet.
• If the loop must never hesitate and the board is small -> embedded Rust on the microcontroller, because hardware keeps time better than an operating system.
• If your robot needs mapping, navigation or a specific vendor driver -> ROS 2 in C++, because those packages are the project and porting them is not.
• If Rust, Python and C++ parts must share data on one machine -> a shared-memory middleware, because the language boundary is what is costing you.
• If your team has a date and no Rust experience -> ship in what you know, then move one component, because half a robot in each language demonstrates neither.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the one that loses on the fewest. No scores and no numbers: five honest questions about your situation rather than about the software. If your robot keeps landing on one machine with Rust holding the loop and other languages above it, star HORUS on GitHub so it is in your list when you start building.