Python dominates robotics today. C++ is the serious choice. But I’m starting to think we’ve been sleeping on Go. Here’s why I’m actively exploring it.
The Python Problem
Look, I get it. Python is everywhere in robotics. ROS has massive Python support. Every machine learning tutorial starts with Python. There are libraries for everything. It’s fast to learn, fast to prototype, and there’s an army of people contributing packages.
But here’s the thing: Python doesn’t have the performance needed for real robotics.
“But Greg, you can throw more hardware at it!” Sure. And now you’ve just increased your costs to scale. When you’re trying to build a lot of robots, that extra $50 per board adds up fast. The economics don’t work. And still, even on a faster board are you REALLY happy with how fast your python runs?
Python is fast to learn and prototype, but getting it to be really reliable? That’s hard. The very thing that makes it accessible — all those libraries — is also a liability. You don’t know the quality of most of them. Seriously. Some random person published a package three years ago. Does it work? Is it maintained? Does it have trojans inside?
People worry about not reading code that AI writes. But have they read all the modules that are included in what they write? Especially in Python or JavaScript? Hmmm.
And here’s the kicker: any real work in Python is going to require modules that use C under the hood for performance. NumPy, OpenCV, PyTorch — all C or C++ inside. Now you have cross-compile complexity, since so much of robotics runs on ARM. You’re not really “just using Python” anymore. You’re managing a multi-language stack whether you like it or not.
The C++ Reality
C++ is heavily used in production robotics today, and for good reason. It’s fast. There’s a lot of mature code out there, and it’s likely to be better quality than your average Python package.
But hoo boy, C++ is hard to master.
Is it really faster than Go? For most robotics workloads, the answer is “maybe marginally, but probably not enough to matter.” Go is fast. Compiled, statically typed, garbage collected (yes, GC, but with low latency that’s been getting better every release).
The bigger issue with C++ is that getting all that code to play nicely together is a lot of work. Build systems, dependency management, ABI compatibility — it’s a full-time job just wrangling the toolchain.
And here’s something I’ve been noticing: AI assist is less viable in C++ since today’s LLMs admit they are weak in C++. They’ll happily generate Python or Go all day, but ask them for complex C++ and they start hallucinating memory leaks and template metaprogramming nightmares.
Go’s Secret Weapon: Simplicity
Go is a vastly simpler language than C++. That’s not a bug, it’s a feature.
Getting multi-threaded code right in C++ requires an extremely high level of skill. Mutexes, condition variables, memory ordering, lock-free data structures — even experienced developers get this wrong. And in robotics, you need concurrency. Sensors, actuators, planning loops, communication — it’s all happening simultaneously.
Go’s concurrency model is just… better. Goroutines and channels make concurrent programming almost easy. I’ve written concurrent code in both, and the difference in cognitive load is massive. In Go, I can focus on the actual problem. In C++, I’m constantly thinking about whether I’m going to deadlock or race.
The AI/ML Intersection
The future of robotics intersects heavily with AI and machine learning. Today, a lot of that work happens in Python. And where Python isn’t fast enough, it drops down to C++.
But here’s the challenge: that means you’re managing complexity across two very different languages, each with their own ecosystems, build systems, and deployment strategies.
Why not do more foundational robotics and AI work in Go?
Go has decent ML libraries emerging. TensorFlow has Go bindings. ONNX runtime works with Go. Is it as mature as Python? No. But the ecosystem is growing, and you get single-binary deployment, easy cross-compilation (hello, ARM!), and performance that’s close to C++ without the complexity tax.
What I’m Exploring
This is what I’m actively investigating. I don’t have all the answers yet.
Can Go really handle the performance requirements of real-time robotic control? What about interfacing with existing ROS ecosystems? How mature are the hardware interface libraries?
These are open questions. But I’m increasingly convinced that the current Python-for-prototyping-C++-for-production pipeline has more friction than it needs to. Go sits in an interesting middle ground — faster than Python, simpler than C++, with excellent tooling and cross-compilation built in from day one.
Conclusion
The robotics stack is ripe for reconsideration. Python’s ease of use comes with hidden costs. C++’s performance comes with complexity that slows everything down. Go offers an intriguing alternative that combines reasonable performance with genuine simplicity.
I’m not saying everyone should throw out their existing stacks and rewrite everything in Go. That would be crazy. But for new projects, especially ones where you want to move fast and deploy reliably at scale? Go deserves a serious look.
I’ll keep exploring this and share what I learn. If you’re doing robotics in Go, or thinking about it, drop me a note. I’d love to hear what’s working and what isn’t.