There is a brief, beautiful period in every robotics project when you don’t know enough to realise what you’ve signed up for.
You order two motors, a board, and some sensors. Reasonable purchases. The robot only needs to move around without hitting things. Then you get to the software.
Python looks approachable. C++ looks like it expects you to arrive with prior work experience. You search which one to use, hoping for a straightforward answer, and accidentally enter a debate that has been running longer than most robots.
To understand why, we need to ask something the debate tends to skip: what exactly are you making this robot do?
What Exactly Are You Making This Robot Do?
This is the part almost everyone rushes past. They jump straight into “Python is easier” or “C++ is faster” without ever defining the job.
Is this a research prototype that needs to test five different perception pipelines before lunch? or Is it a mobile base that has to navigate a warehouse without hitting humans? Is it a robotic arm that must close a gripper at the exact millisecond a fragile object enters its reach? Or is it a social robot whose main task is looking cute on Instagram while occasionally waving?
These are not the same problem. A robot that needs to explore ideas and change its mind every afternoon has completely different language requirements than a robot that must guarantee it will never miss a 5-millisecond control deadline. Treating them as identical is how you end up with a system that is either too slow to be useful or too rigid to iterate.
Choosing a language without knowing the job is like choosing a vehicle without knowing the destination. The most important thing to figure out is how your robot deals with time. Robotics has a concept called real-time, and it comes in two flavors:
Soft real-time: being late is annoying. A camera frame arrives 40 milliseconds late, the robot hesitates, and everyone moves on with their lives.
Hard real-time: being late is a failure. A motor controller misses its deadline, and your robot arm gets confident in the wrong direction.
A robot that identifies fruit on a conveyor belt lives mostly in the first world. A robot balancing on two legs lives in the second. A robot that falls over at the wrong moment doesn't send an error message. It sends you a repair bill.
Pro tip: Write down your robot's slowest acceptable reaction time before writing a single line of code. If you can't name a number, you aren't ready to pick a language.
Python: The Language of "Let's Just Try It"
Python is the friend who says "sure, let's go" and means it. You can go from idea to a blinking LED before your coffee gets cold. The syntax reads almost like English, the learning curve is gentle, and the ecosystem is enormous: OpenCV for vision, NumPy for math, PyTorch for machine learning, and rclpy for writing ROS 2 nodes.
That makes Python the natural home for anything involving thinking rather than reflexes:
Prototyping a new idea over a weekend.
Running computer vision and ML inference.
Writing high-level behavior logic ("if battery low, go home").
Test scripts, data analysis, and simulation tooling.
Now the honest part. Python is interpreted, so it's slower than compiled code at raw computation. It also has a garbage collector that cleans up memory whenever it decides to, which is fantastic for convenience and terrible for exact timing. Add the Global Interpreter Lock, which limits true multithreading, and you get jitter: tiny, unpredictable delays in when your code actually runs.
Python is also dynamically typed, so many typos don't show up until that exact line executes. In a normal app, that's a crash. In a robot, it's your arm discovering a NameError mid-swing, at which point the arm is no longer following your plan.
One important twist, though: when you call OpenCV or NumPy from Python, the heavy lifting happens in optimized C and C++ underneath. Python often acts as the polite manager telling fast C++ workers what to do. That's why "Python is slow" is only half the story.
C++: The Language of "It Must Never Fail"
If Python is the friend who says "let's try it," C++ is the engineer who says "let's prove it won't blow up first." It compiles to native machine code, gives you precise control over memory, and has no garbage collector sneaking in to tidy up at a bad moment. When you need something to happen exactly when you said it would, C++ is the tool.
That's why the serious, time-critical parts of the robotics world tend to be written in it: motor control loops running at 1 kHz or faster, sensor drivers, state estimators, and the performance-heavy cores of big projects like MoveIt and Nav2. In ROS 2, rclcpp is a first-class citizen for good reason.
C++ also has a strong static type system, so a whole category of silly bugs gets caught at compile time, on your desk, instead of at runtime, on your robot. That's a seriously underrated safety feature.
Now for the price. C++ gives you power, and power comes with a bill:
Segfaults: your program dies with a message that would make a fortune teller shrug.
Undefined behavior: the code compiles, runs, and works... until Thursday.
Build systems: CMake is a rite of passage with a side of trauma.
Slow iteration: change a line, wait for a rebuild, drink more coffee than is medically advisable.
C++ is brilliant when you know exactly what you're building. It's miserable when you're still figuring out what the robot should even do. Writing your first experimental idea in C++ is like building a house to test whether you like the color of the walls.
The Real Architecture Almost Nobody Talks About
Here is the secret that ends the argument: robots don't pick one language. They use both, in layers, and each layer uses the language that fits its job.
Think of your own body. When you touch a hot stove, your hand jerks away before your brain has formed the thought. That's your spinal cord: fast, simple, automatic, and not interested in discussion. Your brain handles the slower, smarter stuff: "maybe don't cook while watching robot videos."
A well-built robot follows the same design:
Top layer (the brain): Python. Behavior logic, ML inference, mission planning, test tools, and glue code. Flexibility matters more than microseconds here.
Middle layer (the nervous system): C++ nodes. Perception pipelines, SLAM, motion planning, and state estimation. These need real speed but not the strictest timing.
Bottom layer (the reflexes): C or C++ on a microcontroller. Motor control, PID loops, and safety stops. Deadlines are law down here.
ROS 2 makes this easy because nodes talk to each other by publishing and subscribing to messages, and they don't care what language the other node was written in. A Python node can happily tell a C++ node where to go, and the C++ node will respond without any language drama.
So the rule of thumb is simple: use Python where the robot thinks, and C++ where the robot reacts. The war was never real. It was a layering problem wearing a trench coat.
Ask Your Robot These Three Questions
When the language debate starts heating up again, force the conversation back to the machine. Ask these three questions:
Am I still figuring out what this robot should even do?
If the answer is yes, start in Python. Speed of learning matters more than microsecond performance. You can always rewrite the critical pieces later once you know what they are.Does any part of the system need guaranteed timing or hard real-time behavior?
If yes, that part belongs in C++ (or another language with real-time capabilities). Do not pretend Python will somehow become deterministic just because you really want it to.Will this robot need to run reliably for weeks or months with minimal drama?
If the answer is yes, design the Python/C++ boundary on purpose instead of discovering it in a panic three days before the demo. Decide early which components must never fail and which ones are allowed to experiment.
These questions cut through most of the noise. They also force honesty. A lot of projects claim they need C++ performance when what they actually need is better mechanical design or clearer requirements. Others stay in pure Python long after the control requirements have outgrown it.
The right choice is the one that matches the actual constraints, not the one that wins the most arguments online.
