Rust Robotics Jobs: Is the Demand Real?

Rust robotics jobs are real but narrow, concentrated in autonomy startups and embedded teams, while ROS 2 with C++ and Python holds most adverts. Demand follows a specific need, code that runs for weeks without falling over, rather than a general shift, which is why Rust-first projects such as HORUS hire for it and most large employers do not. It flips on a team starting a codebase from nothing. The rest of this post is for a Rust developer weighing whether robotics is a place to spend the next two years.

You have been watching the same job board for a month. Search for Rust and you get payments infrastructure, a database company, three crypto firms and one robotics advert that turns out to want C++ with Rust listed at the bottom under "bonus". Search for robotics and you get a wall of C++ and ROS 2 and a masters degree you do not have. Somewhere in between is the thing you actually want, which is to be paid for the language you already like, working on machines rather than on request handlers.

The forums are no help. One thread says every serious robotics company is quietly moving to Rust and the adverts have not caught up yet. The thread underneath says nobody hires for Rust in robotics and you should stop kidding yourself. Both are written with total confidence and neither cites anything. Meanwhile you are deciding whether to spend your evenings on a robot kit, and you would rather not learn in a year that you picked the wrong half of a field you cannot get into.

Is there real demand for Rust robotics jobs?

The demand is real, and it is narrow rather than broad. Rust appears in robotics hiring in a few identifiable places: firmware and motor control on small chips, the parts of an autonomy stack that must not fall over unattended, supervisors and fleet services, and new codebases at companies founded recently enough to have chosen. Those are real roles with real salaries, and they are a small share of robotics hiring overall. What you will rarely find is an advert with "Rust Robotics Engineer" as the title. What exists instead is a robotics role at a company whose newer code happens to be Rust, where the advert lists Rust alongside C++ and expects you to read both. The demand is also growing for a boring structural reason rather than a fashionable one. Language choices happen when a codebase starts, almost never afterwards, and a steady stream of new robotics companies has been starting codebases. Every one of those choices is permanent for years, which means the Rust share of robotics work grows slowly and does not shrink.

What does a Rust robotics job actually involve?

Mostly it involves robots, not Rust. The language is perhaps a third of the working day at the companies that use it most, and the rest is the same work every robotics engineer does: chasing a sensor that reports nonsense when the motor draws current, working out why the arm reaches the right position in the wrong order, reading logs from a machine that stopped overnight, and standing in a lab holding a laptop while somebody else holds the robot. The Rust part is usually a specific slice. It is the process that talks to the motor controller, because that one must never panic and take the machine with it. It is the supervisor that notices a component died and restarts it. It is firmware on the board underneath, and the tooling that ingests a week of logs. Interviews follow the same shape. You will be asked about coordinate frames, timing, what happens when a message arrives late, and how you would test something that only fails on hardware. You will not be asked to recite the borrow checker's rules.

What are your actual options if you want to be paid to write Rust for robots?

There are five routes, and they suit very different people. The first is joining an established robotics company with a C++ and ROS 2 stack and becoming the person who introduces Rust in one corner, usually tooling or a new service, which is slow but employs the most people. The second is embedded Rust on microcontrollers and motor boards, the corner where adverts name Rust directly. The third is an autonomy startup that chose Rust at founding, where you write Rust all day and accept startup risk. The fourth is building on a Rust-native message layer: ROS 2 is the large ecosystem with community Rust bindings and thousands of ready packages, while HORUS is a smaller open-source project under Apache-2.0 where Rust, Python and C++ processes share the same shared-memory ring buffers, so messages between processes on one machine are never serialised. The fifth is staying in infrastructure Rust, where the money and the openings are, and building robots at weekends until your portfolio makes route one or three possible. Most people who succeed use the fifth route to reach one of the others.

How do the routes into Rust robotics work compare?

Read the last column first. Each of these routes fails for a specific person, and the failures are more informative than the pitches.

No row here is a trap. The rows differ in how long you wait before the work looks like what you imagined.

What should you do if you are already a Rust developer with no robotics experience?

Learn the robot, not the language, because your Rust is not what is stopping you. Hiring managers assume a competent systems programmer can be taught their codebase. What they cannot teach quickly is the set of instincts that only comes from hardware: that a sensor lies in a specific direction when the battery sags, that two components disagreeing about which way is forward will produce behaviour that looks like a planning bug, that a timestamp taken when a message was read is not the same as when the measurement happened. Buy the cheapest machine that moves under its own power and make it do one thing without you standing over it. Write down the failure that took longest to find. That paragraph is worth more in an interview than a rewritten library with no hardware attached, because it proves you have met the actual job. If you want the wider map of what employers are screening for, the skills that are getting hired is a more complete answer than any single language.

What kind of robot hardware do the Rust jobs actually sit on?

Two clusters, at opposite ends of the machine. At the bottom are small chips: motor boards, sensor boards, battery management, anything with no operating system, where a memory bug means a limb moves when it should not and the fault reproduces once a fortnight. That corner has adopted Rust faster than any other part of robotics and hires for it by name. At the top are Linux computers on machines expected to run unattended for weeks, delivery robots, warehouse fleets, agricultural equipment, inspection drones, where the cost of a crash is a truck roll rather than a restarted process. In between sits the largest population of robots, hobby platforms and research arms and teaching kits, which are overwhelmingly Python and C++ and will stay that way because nobody is paying for the qualities Rust provides. If your interest sits in that middle band, the honest reading is that Rust's readiness for robotics is not your limiting factor and the job hunt will be easier in another language.

What can you realistically show for yourself in three months?

One machine doing one thing, on video, with the code readable by a stranger. Three months of evenings is not enough to become a robotics engineer and it is comfortably enough to stop being a candidate with nothing physical to point at. Pick something small enough to finish: a wheeled base that patrols a corridor and stops when a person steps in front, an arm that picks one object off a table and puts it in a box, a sensor rig that logs a week of data and survives a power cut. Write the part that touches hardware in Rust and everything else in whatever is quickest, because that split is exactly what employers do. What eats the three months is not the language. It is the week spent discovering your motor driver has no Rust support, the weekend where the robot works on the bench and fails on carpet, and the evening lost to a loose connector. Budget for those and finish anyway.

What if you have never written Rust and are deciding whether to start?

Start with Rust if you already know a systems language, and start with robotics if you do not. A C++ developer moving to Rust is learning new rules for a job they already understand, and the crossover takes weeks of irritation rather than months. A Python developer moving to Rust is learning ownership, borrowing, a compiler with strong opinions and a build system, all while also learning robots, which is two hard things at once and a common way to quit. The order that works for Python developers is to get a robot working first, in Python, and let the machine tell you which single piece needs to be stricter. Often that piece is smaller than expected and the rest of the robot stays in Python permanently, especially the decision-making layer, where the language you write behaviour logic in is chosen for readability rather than for timing. Coming to Rust after meeting the bugs Rust prevents is faster and much less demoralising than coming to Rust out of duty.

What do Rust developers try first when they look for robotics work, and why does it stall?

They filter job boards for the word Rust, and it stalls because robotics roles are advertised by domain rather than by language. That filter surfaces a handful of openings, most of them at companies you have already found, and hides the larger set of teams that write some Rust internally but advertise for a "perception engineer" or a "controls engineer" instead. The search that works is the reverse: find companies making the kind of machine you want to work on, then look at their engineering writing, their conference talks and their open repositories to see what the newer code is written in. The second thing people try is a portfolio project that rewrites a well-known robotics library in Rust. It stalls because a reviewer cannot tell from the repository whether the rewrite ever controlled anything, and the questions they wanted answered, about hardware and timing and failure, go unanswered. A modest robot that moves badly and is documented honestly beats a polished rewrite that never left the laptop.

What do you give up by betting the next two years on Rust in robotics?

You give up the largest pool of employers, and that is a real cost rather than a rhetorical one. The majority of robotics jobs maintain existing C++ code, and a candidate who cannot comfortably read C++ is not shortlisted for them regardless of how good their Rust is. You give up the ready-made ecosystem for a while, since the driver for the exact camera or lidar a job uses is usually written in C++ with a Python binding, and writing your own is a week you did not plan. You give up some of the tutorial world, because the courses, the textbooks and the university curricula are built around other languages. And you give up a certain amount of patience: choosing Rust in a team that has not chosen it means arguing for it repeatedly, being asked to justify build times, and watching your corner get rewritten if you leave. None of that argues against Rust. It argues for keeping C++ readable to you while you specialise.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever your goal is employment rather than language preference, which is most people reading this. If you want the widest set of companies to consider you, ROS 2 with C++ and Python is what the adverts ask for, what the interviews test, and what most robots in the field are running today. If you are a student, ROS 2 is what your coursework, your competition team and your first internship will use. If you are joining an existing company, their fleet is already built on something and your first year is spent inside it rather than choosing. If your ambition is a specific employer, look at what that employer ships and learn that, even when it bores you. And if what you want is a job offer within the year, HORUS is not the answer, because a smaller project appears in fewer adverts and hires fewer people than an ecosystem that a decade of robotics has standardised on. The narrower case where a Rust-native stack earns its place is a new team, on new hardware, choosing once.

Is Rust hiring in robotics just online enthusiasm?

Partly, but not the way you think. The enthusiasm is genuinely disproportionate: the volume of forum posts about Rust in robotics far exceeds the volume of Rust in robots, and a newcomer reading only forums will badly overestimate how many teams have moved. What that reading gets wrong is the direction of the mistake. The enthusiasm is loud and early, not false. Underneath it are engineering managers who have spent a night chasing a memory fault that only appeared after the machine had been running for days, and who quietly decided that the next component would not be written in a language that permits it. Those decisions do not generate forum threads. They generate one new service in Rust, then another, then a hiring requisition that mentions Rust in the third bullet. The correct summary is that the noise is ahead of the hiring, the hiring is ahead of the adverts, and the adverts are the only part you can see from outside.

Does knowing Rust mean you can skip C++?

No, and here is why the idea keeps circulating anyway. Rust genuinely covers the ground C++ covers on a robot, so on a blank page you could build an entire machine without touching C++. Robotics is not a blank page. The vendor library for your depth camera is C++. The motion planner your team relies on is C++. The framework internals you will eventually have to read when something behaves strangely are C++. The codebase you are hired to maintain is C++, because it was written before the choice existed. A candidate who cannot read that code is asking an employer to route work around them, which small teams cannot afford. The version of the advice worth keeping is narrower and true: you do not need to be a C++ expert, and you do not need to write new C++ by preference. You need to be able to open an unfamiliar C++ file, follow what it does, and change one line without breaking the build. That is a far smaller investment than the internet implies, and it widens the set of jobs you can apply for.

How do you decide whether to learn Rust for the job you want?

Decide from the machine, not the language. Write down the kind of robot you want to be paid to work on, then find three companies making it and read what their engineers publish. If those companies are shipping firmware, drones or long-running field machines, Rust is a sound bet and you should also learn enough C++ to read theirs. If they are research labs, humanoid startups doing learned control, or anyone whose demos are full of neural networks, your evenings are better spent on Python and on getting hardware to obey you. If you cannot find three companies, that is the most useful signal here, and it means the niche is smaller than the internet suggested. The one situation where Rust decides quickly is a new team with a new codebase, because the language is picked once and then inherited by everyone who joins afterwards, which is exactly the moment your preference is worth arguing for.

Where that leaves you, in five lines:

• If you are a Rust developer with no robot yet -> finish one small hardware project, because employers hire evidence of a moving machine, not a language preference.
• If you want the widest choice of employers -> ROS 2 with C++ and Python, because that is what the adverts ask for and the interviews test.
• If you like small chips and firmware -> embedded Rust, because that corner names Rust directly instead of listing it as a bonus.
• If you are joining a team starting a fresh codebase -> argue for Rust now, because the language is chosen once and inherited for years afterwards.
• If you need income while you switch -> infrastructure Rust plus robots at weekends, because a portfolio moves you sideways later.

The HORUS Fit Framework is the short version of that reasoning applied to whatever a team builds on: judge an option on five axes, which are ecosystem size, setup effort, team size fit, deployment target and licence, then pick the one that loses least on the axis you cannot afford to lose. Job seekers lose most often on ecosystem size, because that axis is also the hiring pool.

HORUS is open source under Apache-2.0 at github.com/softmata/horus. Star it so it is in your list when you start building.