Python vs C++ for Robotics: What Most Guides Get Wrong

Most robots use both languages: Python for the parts that change daily, C++ for the few parts that must keep time. Guides get it wrong by asking which language a robot is written in, when the decision is where the boundary sits. That flips on a bare microcontroller, where C is the only door in — on a full computer, ROS 2 and HORUS both cross languages. The rest of this post is for a beginner who has read ten of those guides, has no robot yet, and wants to stop reading and start building.

You have read the same article nine times with different headers on it. There is a chart. There is a paragraph explaining that C++ is compiled and Python is interpreted, which you already knew. There is a sentence saying to pick Python if you value development speed and C++ if you value execution speed, as though those were two dials on the same box and you were being asked to choose a mood.

None of it tells you what to do on Saturday. Your motor driver is still in its bag, your board is still in its box, and you cannot connect any of the advice to the actual question, which is what to type first.

Then you find a forum thread where someone says that anything not written in C++ is a toy and that real engineers do not use Python for control, and somebody else replies that this is gatekeeping and their whole drone flies on Python. Both of them sound certain. Neither shows you their robot. You close the tab knowing only that you might be doing it wrong already, and the box stays shut another week.

Should you write your robot in Python or C++?

Write it in Python, and move the one part that cannot live there into C++ when the robot tells you which part that is. This is not a compromise answer, it is what working machines actually look like: the layer deciding what to do next is written in a language you can change quickly, and the layer that must act on a fixed rhythm is compiled. Starting anywhere else costs you time you cannot get back. If you begin in C++ alone, you meet a language, a memory model and a build system before a single wheel turns, and self-taught beginners overwhelmingly stall in the build system, which teaches them nothing about robots. If you begin in Python you have something moving in an evening, and every evening after that adds a behaviour rather than a configuration file. The exception is genuine and common: if your robot is a microcontroller with no operating system, the board has already decided, and that decision is C. Everything below is about full computers, where you have a choice to make and a boundary to place.

What does robot software actually break down into?

Robot software breaks into five layers, and only one of them argues about languages. At the bottom sit drivers, the code touching hardware directly, and they are written in C or C++ because that is what chip makers and camera vendors ship, whether or not you author a line of it. Above that sits the control loop, the part correcting the machine over and over so it holds a line or a position. Above that sits perception, which is usually a Python front door onto compiled libraries somebody else wrote. Above that sits behaviour: drive to the kitchen, look for the cup, give up and go home. And around all of it sits tooling — logging, plotting, replaying a bad run, checking whether yesterday's change helped. Count the lines you will personally write and most of them land in behaviour and tooling, which change constantly and are happiest in Python. The control loop is the contested layer, and it is a small fraction of the code and most of the argument. Knowing that split makes the whole comparison stop feeling like a personality test.

What do most guides get wrong about this comparison?

They treat it as one choice for the entire robot, which no working robot has ever been. That framing produces every other mistake in the genre. It makes people benchmark loops of arithmetic, when robot code spends its life waiting for a sensor, moving an image from one place to another and talking to a driver. It makes people ask which language is faster, when the question a machine cares about is whether this cycle takes roughly as long as the last one — a program that is usually quick and occasionally pauses will make an arm jerk, while a program that is steady will not. It makes people ignore borrowed code, even though the language of your camera driver, your motor library and the example your board shipped with decides far more than your preference does. And it ignores the only decision that genuinely costs you something: once you use two languages, there is a boundary between them, and data has to cross it. That crossing is where copies pile up and where the confusing bugs live. Choosing a language is easy. Placing that boundary is the actual skill.

What are your actual options, and who is each one for?

There are eight realistic options, and several of them are combinations rather than a single language. You can write everything in Python and stay there far longer than the internet suggests. You can write everything in C++ because your course, your team or your board already does. You can put Python on top and C++ underneath, which is where most robots end up. You can work in embedded C on a microcontroller. You can reach for Rust in the demanding parts. You can adopt ROS 2, which supports Python and C++ side by side with shared message definitions, so perception can be written in one and control in the other. You can adopt HORUS, an open-source real-time robotics middleware for Rust, Python and C++ under Apache-2.0, where all three languages share the same shared-memory ring buffers so processes on one machine trade messages without serialising them. Or you can stay inside the vendor's kit and write whatever it documents. Read the table as descriptions of situations, not as a ranking.

Which language fits someone building alone in the evenings?

Python, because your scarce resource is evenings and not processor cycles. A solo builder gets perhaps two useful hours on a weeknight, and the difference between two hours that end with a servo sweeping and two hours that end with an error about a linker is the difference between carrying on and quietly stopping. Momentum is the entire game when nobody is grading you. There is a second reason that matters more than it sounds: when you are alone, the size of the answer pool decides how long you stay stuck. Beginner questions about Python and hardware have been asked and answered by thousands of hobbyists in short, direct replies, while the equivalent C++ question often gets an answer about templates. The honest counter-case: if you are learning in order to join a team, or to work on a machine whose driver layer is entirely C++, learn the language of the thing you want to touch and accept slower evenings for a while. Learning in a vacuum favours Python; learning towards a destination favours whatever that destination speaks.

What if your robot is a small board with no operating system?

Learn C, because the board has already made this decision and arguing with it costs you months. A microcontroller has no operating system, no package manager and very little memory. The vendor's examples are in C, the datasheet describes registers rather than objects, and the answers you find online will be in C. That environment is not hostile to beginners, it is just narrow, and the narrowness is why so many people learn more about machines from a small board than from a full computer. MicroPython is a legitimate on-ramp rather than a shameful one, and running an interpreter on a chip lets you change one line, reflash and watch the behaviour change, which teaches you what your motors really do. Where it stops is predictable: a behaviour reacting at human speed is fine, and a machine correcting itself constantly against a changing load, like anything that balances, will show the interpreter's pauses as a wobble you can watch. When that day comes, the fix is not cleverer Python, it is moving that one behaviour into C while the slower parts stay put.

What if something has to move before a deadline next month?

Choose Python and do not reconsider, because a deadline is the worst possible moment to learn a build system. A month is enough time to make one machine do one thing convincingly, and that is what a deadline actually rewards; it is not enough time to learn a language, a toolchain and your own robot at once. The people who miss deadlines in robotics rarely miss them because their language was too slow. They miss them because a driver would not install, a cable was intermittent, a sensor needed calibrating twice, or nobody had decided what the robot should do when the object is not there. All four of those problems are language-independent and all four eat weeks. So spend your month on the machine rather than on the toolchain, and accept that the result will be a demo rather than a product: one file, sequenced by luck, working on a specific table in specific light. Decide in advance which parts you plan to throw away and write those parts carelessly on purpose, so that the rewrite later is a rewrite and not an excavation.

What if you have never written any code before at all?

Start with Python, and do not start on the robot. This is the one case where the hardware should wait a week or two, because learning to program and learning to wire things at the same time means every failure has two possible causes and you cannot tell them apart. Nothing happened when you ran the program: is the code wrong, the wiring wrong, the motor unpowered, or the sensor dead? A first-time programmer cannot answer that, and whole weekends vanish into it. So spend a short while with Python on a laptop — variables, loops, functions, reading an error message without panicking — until a program failing feels ordinary. Then plug in one sensor and print its number. Then one motor. Then both. That sequence looks slow and is the fastest route anyone has found. C++ can absolutely be a first language, and university courses prove it every year, but those students have a lecturer, a lab, a deadline and twenty peers hitting the same error. Alone in the evenings that scaffolding is missing, and the language feels far harder than it deserves to.

What do beginners try first, and where does it stop working?

Beginners pick one language for the whole robot because a guide told them to, and it stops working in two different ways depending on which one they picked. The C++ path usually stops before the robot exists. Weeks go into a build system, an unfamiliar error about linking appears on a Saturday morning, and the project quietly ends with nothing having moved. The Python path gets much further and stops later, when one part of a working machine starts to hesitate. Here comes the expensive mistake: having decided Python was the problem, people begin rewriting the entire robot in C++. That rewrite takes a season, replaces working behaviour code with unfamiliar code, and fixes a problem that lived in one loop. The proportionate move is to take the single part that must keep time, move that alone, and leave everything else exactly where it is. Robots that mix languages are not compromises or half-finished migrations. They are the normal shape of the thing, and whether to use one language or several is worth reading before you commit to a rewrite.

What do you give up by writing most of the robot in Python?

You give up early intuition about what the machine is really doing, and that debt comes due later. A Python-first builder can get a robot working without ever thinking about where memory comes from, how long anything takes, or what happens when two parts of a program want the same data at the same moment. That ignorance is a gift on day one and a bill in month six, because the day your loop starts hesitating you are debugging a category you have never had to think about. You also give up some hardware outright, since the smallest chips will not run Python at all, and you give up a slice of job adverts that filter on C++ before reading further. There is a quieter cost too: getting a Python environment onto a robot and keeping it the same across a reflash is its own chore, and it surprises people who assumed the hard part was the code. None of this is lost, only deferred, and you pay it back holding a robot instead of a certificate.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the code you actually need has already been written by somebody else, and the language question is secondary to that. A robot that must map a building and drive to a goal is a ROS 2 project, because navigation and mapping represent years you cannot reproduce in evenings. An arm planning around obstacles is one for the same reason. If the sensor you bought ships exactly one usable driver and that driver is a ROS 2 package, the decision has been made for you. If your system spans a robot and a workstation, or will one day be a fleet, ROS 2 was designed for that shape and is well travelled there. If you are joining a lab or a company where everyone speaks it, shared vocabulary beats any technical comparison. HORUS is not the answer in those cases, and choosing it there means rebuilding plumbing that already exists so you can lose the packages that were the point. ROS 2 also settles the language argument neatly for a beginner: Python and C++ share the same message definitions, so a node can change language without changing how anything talks to it.

Is C++ required before anyone takes your robot seriously?

No, and here is why: the requirement was never for the language, it was for predictability in a small part of the system. What genuinely needs a compiled language is code that must do the same thing in the same amount of time every cycle, plus code sitting directly on the hardware. On most machines that is a minority of the lines and a minority of the effort. Perception pipelines, mission logic, calibration tools, data collection and evaluation scripts are routinely Python inside companies shipping serious machines, and nobody there considers that embarrassing. The belief that C++ is a gate persists because adverts for control roles ask for it loudly. The useful reframing is that C++ is a tool you reach for at a specific moment, when something must not hesitate, rather than an entry fee you pay before touching a robot. Beginners who accept the gate version delay their first machine by months and often never build one. Beginners who accept the tool version build something, feel where it hesitates, and learn C++ with a reason attached.

Is Python too slow to control a robot?

Partly, but not the way you think. The problem is rarely that Python is slow on average, because a great many robots are steered perfectly well from Python while a motor controller or a small board handles the fast, repetitive correction underneath. The problem is that Python pauses at moments you did not choose, and a control loop cares far more about doing the same thing every cycle than about being quick on average. A correction that arrives late is not a smaller correction, it is one aimed at where the arm used to be. That is why the symptom people report is a machine that mostly behaves and occasionally twitches, rather than a machine that is uniformly sluggish. It also explains why the fix is targeted rather than total: put the part that must keep rhythm where rhythm is predictable, and leave the rest alone. If you want the longer version of this argument with the specific cases where Python holds up fine, whether Python is fast enough for robot control goes through them one by one.

How do you decide which language to open tonight?

Name the thing you want to see happen this month and let that choose for you, because no general argument about languages will ever resolve. If the answer is a wheel turning, a servo sweeping or a camera spotting something, open Python and have it working before the weekend ends. If the answer is a specific board with no operating system on it, open the vendor's C examples, because the board decided already. If the answer is a codebase or a team you want to join, open whatever they write. Then keep one tie-break question in your pocket for later, when a working robot starts misbehaving: is the hard part behaviour I have to invent, or timing I have to hold? Invented behaviour favours the language you can iterate in. Held timing favours the language that does the same thing every cycle. If you are coming at robots from model-building rather than from electronics, the difference between embodied AI and physical AI covers the same boundary from the other side.

Decide by situation rather than by preference:

• If you are teaching yourself in the evenings -> Python, because momentum is the resource you are short of.
• If your robot is a chip with no operating system -> C, because the board and its examples already chose.
• If one part of a working robot has started to stutter -> C++ for that part only, because the rest of it is fine.
• If you are joining a team or an existing codebase -> whatever that codebase speaks, because reading it matters more than liking it.
• If the machine must run all day beside a person -> Rust as a later language, because the compiler catches what crashes robots.

When the foundation question arrives — and it arrives the day two languages have to share data on one computer — weigh it on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. No scores and no numbers, just the option that loses on the fewest axes for the robot in front of you. If your machine is heading towards a Python layer, a compiled layer and a boundary between them that you would rather not build yourself, star HORUS on GitHub so it is in your list when you start building.