Why the Slowest Language Won AI

Okay, so this morning my phone suggested a route around traffic, then recommended a playlist. All before breakfast. And I keep hearing one word behind all of it — Python.

Right, that ordinary moment is exactly where it lives. Python is quietly doing that work, and the strange part is it wasn't designed for any of it.

Wait, it wasn't? I assumed AI people picked it on purpose.

Nope. Guido van Rossum created it at the Netherlands' Centrum Wiskunde & Informatica, as a successor to a language called ABC. Development started in the late 1980s, and the first listed release, version 0.9.0, dates to 1991.

Ninety-one. So it's older than the web, basically.

Practically. And it's a general-purpose language — not built for AI or scientific computing at all.

Then how did it, of all things, end up running machine learning?

That's the story I want to tell. It starts with a limitation. Python's general-purpose origins meant it initially lacked dedicated support for scientific data structures and algorithms.

So the language was easy to read but, what, empty-handed for math?

That's a fair shorthand. And the fix came from the community. In 1995, an MIT graduate student named Jim Hugunin started a mailing list — the Python Matrix Special Interest Group — to discuss numerical operations.

A mailing list. That's, that's the seed of the whole thing?

It really is. Hugunin's proposal emphasized a common array or matrix object, so numerical libraries could interoperate. And the discussions included Jim Fulton, Paul Dubois, Konrad Hinsen — and Guido van Rossum himself.

The language's creator was in the room.

In the conversation, yes. That tells you something about how open this process was.

Okay, so how do we get from a mailing list to the libraries everyone names today?

In layers. NumPy supplies array data structures and numerical routines. SciPy builds on NumPy and provides scientific-computing algorithms. And SciPy is a foundation for higher-level libraries, including scikit-learn and scikit-image.

So it's, like when you stack floors in a building — arrays at the bottom, machine learning on top?

That's the picture. That layered ecosystem — from numerical arrays up to machine-learning libraries — is what makes Python useful for AI work.

But who built these floors? Was this a big company project?

That's my favorite part. SciPy's authors recount the project began in 2001 with little funding, written mainly by graduate students — many without computer-science training.

Grad students without CS training. That's, that's honestly encouraging.

It is. And Travis Oliphant combined elements of two earlier array libraries — Numeric and NumArray — in 2005. NumPy 1.0 followed in October 2006.

Hold on — but is Python actually fast enough for the heavy math? Doesn't AI need serious number-crunching?

No. I mean, no, it isn't fast by itself — and that's the twist. Python serves as the accessible interface, while the libraries provide the specialized algorithms and data structures underneath.

So it's the friendly front door to the fast machinery.

Exactly. The libraries let users reach specialized tools without implementing every algorithm themselves. Python is the glue.

And the community kept compounding, right?

It did. Python is open source, and the Python Software Foundation was formed in 2001 to own Python-related intellectual property. Contributions come from a broad community.

Do we have a sense of the scale?

SciPy's authors report more than 600 unique code contributors. Its 2020 Nature Methods paper counted thousands of dependent packages, more than 100,000 dependent repositories, and millions of downloads per year.

A hundred thousand repos. That's a, that's a small city of dependencies.

It is. And that's the virtuous cycle — more users, more contributors, better libraries, more users.

Which brings me to the number I actually wanted to check. Is there hard evidence Python dominates today?

There is. In 2025, 57.9 percent of respondents to Stack Overflow's Developer Survey reported using Python. That's a seven-point rise over their 2024 survey.

Slow down — how many people are we talking about?

More than 49,000 responses, from 177 countries. And the survey describes Python as a go-to language for AI, data science, and back-end development.

So it's not just AI people — it spread everywhere and AI rode that wave.

That's a fair reading. The readability lowered the barrier for researchers and data scientists compared to something like C++ or Java, and the ecosystem did the rest.

Hmm, but I'd push back a little — readable syntax alone doesn't explain a, a dominance like this. Plenty of languages are clean.

Agreed, and I wouldn't claim syntax alone did it. It's syntax plus libraries plus community, each reinforcing the others. Take away any one and the story weakens.

Okay, that I'll buy. So for someone new to AI, where does that leave them?

Invest where the ecosystem already lives. The tools, the tutorials, the contributors — they're all concentrated in one place, and that concentration is the point.

Which, honestly, is kind of beautiful — a language nobody built for AI became its playground.

And it started with a graduate student's mailing list in 1995. That's the part I'd write down.

So I'm holding this little green board a friend lent me. A Raspberry Pi 5. And they claim it runs actual AI.

It can, and there's a real study behind that claim, not just hobbyist forums. Brian Rodriguez, Nuri Yilmazer, and Joon-Yeoul Oh published work in 2025 doing exactly that on a Pi 5.

Hold on — who are these people? I'm not accepting

Researchers, and their paper describes implementing neural networks for handwritten-digit recognition on the Pi. I wasn't going to let that slide unnamed either.

Okay, digits. So the board watches a camera and names the number it sees?

That's the shape of it. A real AI application is a pipeline: capture input, prepare it in the format the model expects, run inference, and turn the output into an action or display.

Inference — say that one in plain words?

Inference means using a trained model to produce predictions. It's distinct from training, which is the expensive learning step.

So the camera captures the image, then what, the board just... reads it?

Not directly. The image has to be standardized. The Picamera2 library gives Python its interface to the camera, and the data gets converted to RGB — the format TensorFlow Lite and OpenCV expect.

Wait — so all of that, the camera and the conversion, is also Python?

Yes. And the arrays holding the image data are handled with NumPy, a common tool for scientific computing.

Huh.

And it keeps going. A classifier learns from labeled examples — for digits, the categories are the possible digit labels. Scikit-learn uses this exact task as its tutorial example of classification.

So the model learns, then predicts. How does that actually work in code?

you fit the model on training data with labels, then call predict on new data. Two calls, basically. Learning, then applying.

But training on this tiny board — can it really handle that? I mean, it's a, a …

Indeed. It can't comfortably, and that's why the study trains models separately, then deploys them to the board for live inference only.

So the heavy lifting happens elsewhere, and the Pi just runs the finished model.

Exactly. They ran TensorFlow Lite Runtime on the Pi for that live inference, with results shown in the console or overlaid on the image. TensorFlow Lite exists precisely for mobile, embedded, and IoT devices — its docs include an embedded-Linux path covering the Pi.

They even 3D-printed a camera holder for it. That's, that's delightfully handmade.

It is! A custom 3D-printed holder, a camera module, and the board. That's the whole rig.

Okay, but here's my real objection. You could do all this in other languages too. Why does the Pi case prove anything about Python?

Grant the strongest version — yes, other languages can run models. But they'd need separate toolchains: one for the camera, one for the math, one for serving. Here, Picamera2, NumPy, scikit-learn, and the model runtime all speak Python.

So the count of languages across the whole pipeline is... one?

One, from data collection to deployment. That count is the significance. Nobody wrote low-level C to connect the pieces.

Hmm. But what about the hardware side — doesn't the ARM processor constrain—

It does. The Pi 5 uses a quad-core 64-bit Arm Cortex-A76 at 2.4 GHz — no big GPU. So lightweight runtimes and quantization matter.

Quantization, meaning...?

Shrinking the model — quantization and compression adapt it to fit the resources on the device. The AI Camera docs require those steps before deployment.

Wait, AI Camera? That's a different thing from the Pi itself?

Yes, and it's the surprising part. The AI Camera's Sony IMX500 sensor has a neural-network accelerator on the module itself. The camera does the processing and returns results alongside the image data.

The camera thinks.

On the sensor. It even includes an RP2040 microcontroller and 16 megabytes of flash to cache recently used models. And it connects to every Pi model, including the Zero, via the standard ribbon cable.

So what can someone actually run on day one?

Ready-made examples. MobileNet SSD detects objects with bounding boxes and confidence values. PoseNet does pose estimation. Both ship with getting-started instructions.

And — say the pipeline finishes — how does the model become a service something else can use?

You could expose the trained model via a simple web service. It exposes the trained model at an endpoint, and other devices interact with it over the network. Same language, again, all the way out.

a hobbyist board proves convenience, not production power. Training still happened off-board.

Fair — and the strongest version of that objection stands. The Pi case doesn't prove Python is fast. It proves the ecosystem makes the full hardware-to-deployment loop reachable by one person in one language.

One language, board to server. And that's the choice I defend — because the objection about speed was not the bottleneck. The bottleneck was glue, and glue is what Python is.

And that rig started as a 3D-printed holder and a mailing-list language nobody designed for this. That's the whole argument, sitting on a desk.

I keep running into two claims that can't both be true. Python is too slow for real work — and Python is what real AI work uses. Every day.

And they're both correct. That's the paradox worth sitting in before we resolve it.

How? A language can't be slow and fast at the—

Right, and the resolution is that the language you write and the machinery that computes are different things.

So when I write a model in Python, who's actually doing the math?

PyTorch's own docs say its Python frontend calls into C++ for the expensive operations, especially numeric ones. TensorFlow is similar — its Python API is the most complete, and its runtime runs the graphs.

So Python is the, the steering wheel.

That's the picture. NumPy was an early example. Its operations run in compiled code, not Python-level loops. A 2020 Nature paper described it as combining Python's readability with the performance of C.

Give me a concrete case — what does that mean for a person coding?

Think of adding a million numbers. In pure Python, you'd write a loop, and the interpreter walks every step. With NumPy, one vectorized line — the precompiled code does the walking.

Okay, but someone had to realize this split was possible. Who was puzzled?

Early researchers training neural networks asked whether an interpreter could ever keep up. The wrong turn was writing every experiment in C++ and losing days to plumbing. The click was separation: prototype in Python, compute in compiled libraries.

And the stakes got absurd, right? I read something about compute doubling.

A 2018 OpenAI analysis estimated compute in the largest training runs had been doubling about every 3.4 months since 2012. That's the hunger side of the paradox.

Every 3.4 months. What does that even look like for one researcher?

Picture a grad student whose model trained overnight last year — same idea now needs a lab's worth of hardware. That's why Emma Strubell, Ananya Ganesh, and Andrew McCallum's 2019 paper measured training's financial and environmental costs and told researchers to prioritize efficient hardware and algorithms.

But wait — if the GPU does the heavy lifting, does every operation land on it?

No — TensorFlow's GPU guide is honest here. An operation without a GPU implementation falls back to the CPU. And distribution strategies can replicate computation across multiple GPUs, splitting the data among them.

So what would you actually wager on? That nobody needs C++ anymore?

No. The odds might be about three to one that many researchers rarely use C++ — but PyTorch’s C++ frontend exists for low‑latency, multithreaded settings where the interpreter can’t go. Different use cases, not a replacement.

There's also that threading thing — the GIL?

In standard CPython, a thread must hold the Global Interpreter Lock to touch Python objects. Free‑threaded builds arrived experimentally in Python 3.13 — and even those don't automatically speed everything up; there's overhead.

Hmm, so it's not a magic—

It isn't. The compile side is more interesting. torch.compile captures the computation graph and generates machine code through a backend.

Does it work? Numbers?

One PyTorch blog benchmark — NumPy code, their particular case — reported a 9× speed‑up on one core, 57× on 32 cores. That benchmark, not a promise.

Nine times on one core. Fifty‑seven on thirty‑two.

NumPy's simple memory model lets people write hand‑optimized C or Fortran code and pass arrays back to Python.

So the slow language wins because experiments turn around faster — write, run, rewrite — even if each step isn't raw‑speed champion.

That's the resolution we opened with. Both claims were true all along.

So what evidence would change my mind?

Go find it yourself — the PyTorch compiler docs, the free‑threading how‑to, that OpenAI analysis. If a workload exists where the interpreter itself, not the libraries, is the bottleneck at scale — that's the number I'd want to see.