Python won because it was easy. That was the whole trick. And now, in the age of agentic coding, that trick has stopped being an advantage — and quietly became a liability.
First, Give Python Its Due #
Let me be fair, because Python earned its place honestly (even though I personally hate white-space as a separator).
I’ve been here for all the hype cycles — I first coded in BASIC on a TRS-80 with 4K of RAM — and yes, I wrote a TON of perl. I’ve watched a lot of languages come and go. Python is one of the ones that stuck, and it stuck for a very good reason: it was simple to learn and simple to use. You could sit a scientist, a sysadmin, a teenager, or a rusty C programmer down in front of it and they’d be productive by lunch. No ceremony. No boilerplate. Just import
the thing and go.
And that simplicity kicked off a flywheel.
Easy language → lots of people learn it → lots of people write libraries → there’s already a library for that → even more people show up because there’s a library for everything → and round and round it spins, faster every year. Want to parse a weird file format? There’s a package. Talk to some obscure API? Package. Do differential equations on a Tuesday? Package. You almost never had to build from scratch, because someone, somewhere, had already published something.
Now — was that something any good? Eh. Sometimes. The quality of those libraries was, let’s say, variable. Some random person published a package four years ago, and you have no idea if it’s maintained, correct, or quietly abandoned. But it existed, and “it exists and mostly works” beat “I have to write it myself” every single time. That was the deal. That was the magic.
(The same flywheel is exactly what happened with Arduino, by the way — dead-simple to start, an avalanche of libraries of wildly uneven quality, and a community that made hardware hacking accessible to everyone. But that’s a topic for another day. Queue up my gorai conversation!).
So I’m not here to dunk on Python. Python was right for its era. My argument is that the era just ended.
The Flywheel’s Whole Value Just Evaporated #
The single greatest advantage Python had — “there’s already a library for that” — was really an advantage about not having to write code. Writing code was the expensive part. The library ecosystem existed to spare you the expensive part. But writing code isn’t the expensive part anymore.
I can point an agent at a problem and have it generate a clean, tested, purpose-built implementation in the language of my choice. Or port an existing library. Or reimplement the good 20% of some sprawling package that I actually need, without dragging in the other 80% and its seventeen transitive dependencies. The moat that took Python twenty years to build — I can now fill in an afternoon, in whatever language I want.
The flywheel spun on the assumption that human-written code was scarce and precious. That assumption is gone. And once it’s gone, you have to ask a very uncomfortable question: if the library advantage doesn’t matter anymore, what is Python actually still winning on?
Because it sure isn’t winning on getting the thing to run.
Let’s Talk About The Hoops #
Here’s where I lose my patience. Ask an agent to build you something useful in Python and then actually try to run it — on your machine, on a colleague’s machine, on a Raspberry Pi, on a fresh cloud VM. Watch what happens.
Let me enumerate the hoops, because they’re real and they’re everywhere:
Virtual environments. You don’t just run the code. First you create a venv, activate the venv, remember you’re in the venv, and pray nobody runs it with the system Python by accident. Forget to activate it? Enjoy polluting your global site-packages.Which Python, exactly? 3.9? 3.11? 3.13? The code was written against one, your OS ships another, and some dependency pinned a third. Now you’re installingpyenv
to manage Python versions, which is a whole tool that existssolelybecause Python versioning is a mess.pip vs conda vs poetry vs pipenv vs uv. The community can’t even agree on how to install things. Every project picks a different dependency manager, and they don’t play nicely together.The C-extension trap. AnyseriousPython needs C under the hood — NumPy, Pandas, OpenCV, PyTorch, cryptography, half of everything. So now “just install it” means compiling native code, which means you need the right compiler, the right headers, the right system libraries. Miss one and you get a wall of red text about a missing.h
file.ARM and the wheel lottery. So much of the interesting world runs on ARM now — Raspberry Pi, Orange Pi, Apple Silicon, Graviton in the cloud. Is there a prebuilt wheel for your architecture? Maybe! Or maybe pip tries to compile from source on a Pi for forty-five minutes and then fails on the last dependency. I’ve watched it happen. It’sinfuriating.System-level dependencies.apt install this
,brew install that
,yum
the other thing. The package needs a shared library that isn’t in the box, and now your “Python app” is actually a fragile multi-language install with a README full of platform-specific incantations.Cross-platform? Ha. What works on your Mac doesn’t work on the Ubuntu box doesn’t work on the Windows laptop doesn’t work in the Alpine container (surprise — musl vs glibc!). “Works on my machine” is basically Python’s unofficial slogan.
And here’s the punchline: the agent that wrote the code can generate all of this friction, but it can’t make the friction go away. It’ll happily hand you a requirements.txt
and a paragraph of setup instructions, and you’re still jumping through every one of those flaming hoops. We’ve automated the writing and left the pain fully intact.
Yes, you can tell me to put it in a container. Really? For everything?
We’re using 2026 tools to generate 2010 deployment problems.
In Go, You Get Out of Jail Free #
Now let me tell you what happens when I ask an agent to build the same thing in Go. Three things, and I want to take them in order because they build on each other.
a) It’s a simple language the AI knows cold.
Go is small. Deliberately, almost stubbornly small. It was designed so Engineers fresh out of college could be proficient in a few weeks. There’s basically one way to do most things, the standard library is excellent and stable, and the idioms are consistent across the entire ecosystem. That simplicity is rocket fuel for an agent. LLMs are strongest where the language is regular and the patterns are consistent — and they’ll cheerfully admit they’re weak in something like heavy C++ template metaprogramming. Go is the opposite of that. The models write clean, idiomatic Go all day long because there just isn’t that much surface area to get wrong. Simplicity isn’t a limitation here. It’s the feature.
b) Type safety — and I want to lean on this one.
This is the big one. This is the one that should change your mind.
Python is dynamically typed, which was lovely for prototyping and is genuinely dangerous for anything you have to trust. The bug doesn’t show up when you write it. It shows up at runtime, in production, at 2am, when some value that was “obviously” an int turns out to be a string because three functions ago something returned None
. Yes, people bolt on type hints and mypy
now — but they’re hints. Optional. Advisory. The interpreter will still happily run right past them into a wall. Oh, you are being careful in your code? That’s cute. Are all the imports you are using doing that?
Go won’t let you go there. The types are checked at compile time. The thing either builds or it doesn’t. A whole category of failures — the ones that are most likely to slip past a human reviewing agent-generated code — simply cannot compile.
And that matters more, not less, in the agentic era. When an agent is generating large volumes of code faster than any human can carefully read every line, the compiler becomes your most reliable, tireless reviewer. Every type mismatch, every wrong signature, every “you can’t pass that here” — caught before the program ever runs. Type safety turns “hope the agent got it right” into “the compiler proved the shapes line up.” That’s not a nice-to-have. When the machine is writing the code, that’s the guardrail.
c) It cross-compiles to a single static binary.
Here’s the part that still makes me grin. When the Go code is done, I build for whatever machine I’m deploying to — from the same dev box, without touching a single toolchain install:
GOOS=linux GOARCH=amd64 go build -o myapp
GOOS=darwin GOARCH=arm64 go build -o myapp
GOOS=linux GOARCH=arm64 go build -o myapp
GOOS=linux GOARCH=arm GOARM=7 go build -o myapp
That’s it. One command each. Out pops a single, self-contained binary. No interpreter. No venv. No pip install
. No “which Python?” No system libraries to chase down. No wheels to pray for. You scp
that one file to the target — your amd64 server, your arm64 Raspberry Pi, your Apple Silicon laptop, whatever — and you run it. It just goes.
Cross-compiling for a different platform from your dev machine is a built-in feature, not a weekend project. Building a tiny container? Your image can be the binary and nothing else — no OS, no runtime, no attack surface. Deployment stops being a project. It becomes a copy command.
So What’s the Big Deal? #
Enumerate what you actually get with Go, all in one place, because it’s a lot:
- A small, regular language that agents generate flawlessly
- Compile-time type safety that catches the exact class of bugs agents introduce
- A single static binary — no runtime to install, ever
- Trivial cross-compilation to any OS/architecture that matters - no surprises (OK, sometimes there’s some CGO)
- Concurrency that’s genuinely simple (goroutines and channels vs. the C++ mutex minefield)
- One canonical toolchain (
go build
,go test
,go fmt
) instead of a dependency-manager holy war - Fast builds, fast startup, near-C++ performance without the complexity tax
- A standard library so good you often don’t needa third-party package at all
That last one is the quiet kicker. In Python, the whole game was reaching for a library. In Go, a huge fraction of the time, the answer is already in net/http
or encoding/json
or the standard library — no supply chain, no trojan risk, no abandoned-package roulette. (I got into the supply-chain angle in Why Go for Robotics? — go read that one too, it’s the sibling to this post.)
So What Are We Actually Training The Future On? #
Here’s the thought that I can’t shake, and it’s why I bothered to write this down.
Every line of code we generate today becomes training data tomorrow. The models learn from the corpus we produce. So we are, right now, collectively deciding what the next generation of AI is going to be fluent in.
Do we really want to pour more fuel on the fire? More Python — more venvs, more “works on my machine,” more C-extension roulette, more runtime type errors, more of a deployment story that was frankly always held together with duct tape? Do we want to teach the machines that this is how software is supposed to work, and then hand the whole loop back to them to reinforce forever?
Or do we point the flywheel somewhere better?
Because we have a genuine, once-in-a-generation opportunity here. For the first time, the cost of “just rewrite it in a better language” has collapsed to nearly zero. The one thing that locked us into Python — the giant library moat — no longer locks anyone into anything. The agent can generate it, port it, or replace it in whatever language we ask for.
So let’s ask for the language that gives us reliability. Predictability. Type safety. A single binary that runs anywhere without ceremony. Let’s ask for the boring, dependable stuff — because “boring and dependable” is exactly what you want holding up the world when more and more of the code is being written by something that never gets tired and never reads the deployment README.
Don’t get me wrong — Python isn’t going anywhere tomorrow, and I’m not telling you to rip out your data science stack. That would be crazy. But for new work, for the stuff we’re generating fresh with agents right now? We get to choose. And every time we choose, we’re also voting on what the future gets trained to believe is normal.
I know what I’m voting for. Type safety. Single binaries. A language the machines already know backwards and forwards. Reliability over “there’s a library for that.”
Agentic Python isn’t harmful because Python is bad. It’s harmful because we finally have a better choice, and we keep reaching for the old one out of habit.
What are you voting for? Drop me a note on LinkedIn — I’d genuinely like to hear the counterargument.