On March 19, 2026, OpenAI announced Astral would join the company, folding the small team behind uv, ruff, and the newer type checker ty into the Codex team. The announcement itself doesn't cite a number, but the figure that spread afterward, roughly a million minutes of compute saved per week by swapping pip-based installs for uv, is worth treating as an estimate people converged on rather than a confirmed OpenAI statistic. I couldn't run down one single authoritative source pinning that number down, and I'd rather say that plainly than dress up an estimate as fact.

Even as an estimate, it points at something real: the tools holding Python's own ecosystem together are, more and more, not written in Python.

The plumbing is already Rust

Pull back any popular Python library that touches performance, and there's a decent chance Rust is doing the real work underneath.

• Pydantic, the validation library nearly every FastAPI app and half of the LLM-tooling world depends on, moved its core validation engine to Rust years ago. The Rust code used to live in its own repo (pydantic-core). It's since been folded directly into the main pydantic package. At that point the Rust layer stopped being a side project and became the product itself.
• Polars, the DataFrame library eating into pandas' territory, is "written from the ground up in Rust with multi-threaded, vectorized execution," according to its own README. Polars runs a Rust engine underneath a Python front door.
• Hugging Face's tokenizers library, which every transformer-based model leans on to turn text into tokens, lists Rust as its "original implementation." Python is a binding on top, alongside Node and Ruby.
• orjson benchmarks around 10x faster at serializing JSON than Python's standard library, and it gets there the same way: Rust underneath, Python calling in.

And then there's Astral's own trio. ruff, the linter and formatter, claims 10 to 100x speed over Flake8 and Black. uv claims the same order of magnitude over pip. Both are Rust binaries wearing a Python CLI.

None of this is a secret. Anyone who's watched the Python tooling space over the past few years has seen "written in Rust" become a selling point on its own. What's new is that OpenAI put a price tag on how much that matters to running an AI coding agent at scale, even if the exact number is still someone's estimate rather than a receipt.

Why this is happening now, not five years ago

The obvious answer is speed: Rust is fast, Python is slow, faster tools win. That's true, but it's not new. Rust has been faster than Python since Rust existed. What's different now is who's writing the Rust.

My working theory, based on watching agents work on both sides of that divide rather than any published benchmark, is that AI coding agents got better at writing Rust and other systems languages not because the models learned more Rust syntax, but because of what Rust gives an agent back. When an agent writes Python and gets something wrong, it often finds out at runtime, maybe minutes or hours later, maybe never, if the bug is silent. When an agent writes Rust, the compiler tells it immediately: this reference doesn't live long enough, this type doesn't match, this match statement isn't exhaustive. Borrow-checking, Rust's compile-time system for tracking who owns a piece of memory and for how long, is annoying for a human learning the language, but for an agent that can iterate hundreds of times a minute, it's a fast, precise, structured signal to correct against. Tight feedback loops are exactly what agentic coding needs, and a compiler that refuses to compile broken code is one of the tightest feedback loops available.

That changes the economics of where teams put their performance-critical code. If an agent can self-correct its way to working Rust almost as reliably as working Python, and the payoff is a linter that's faster or a JSON parser that's faster, writing the hot path in Rust stops being a specialist's side project and starts being the default move. Keep the parts a human wants to read and modify quickly in Python. Push the parts that need to run fast, over and over, at scale, into Rust, and let the agent handle the unfamiliar syntax.

That's the shift, and "Rust is trendy" doesn't capture it. The real barrier to writing performance-critical code used to be needing a systems programmer on the team. That barrier dropped once agents could write and self-correct in a compiled language, because compiled languages hand an agent far better feedback than Python does. I could be wrong about how much of this is agent skill versus agent labor, since nobody has published a clean before-and-after eval on this specific effect yet, but the pattern of what's shipping tracks the theory.

What Python still wins at

None of this means Python is going away. Nobody is rewriting FastAPI's routing logic or Django's ORM in Rust and expecting Python developers to cheer. What's moving to Rust is narrow: the specific hot paths where speed compounds across millions of calls, like validation, tokenization, JSON parsing, and linting.

Python's real advantage was never raw speed. It's ecosystem breadth: the sheer number of libraries that already exist for gluing one service to another, the size of the hiring pool that already knows the language, and frameworks like FastAPI, which has 101,000+ GitHub stars and has become close to a default choice for building AI and agent backends specifically because it's the fastest path from "I have a model" to "I have an endpoint." None of that depends on Python being fast. It depends on Python being everywhere, and on there already being a library, a tutorial, and a Stack Overflow answer for whatever you're trying to glue together next.

The moat is the ecosystem, not the language. Rust could theoretically build the same breadth of libraries over the next decade, but it hasn't, and rebuilding a decade of glue code and institutional knowledge takes a decade, not a rewrite.

What gets rewritten next

If the pattern holds, the next candidates are wherever a Python library sits directly in a hot loop that AI workloads now hit constantly: embedding generation, vector similarity search, and the preprocessing steps that sit between raw data and a model call. Rust-backed vector search libraries like Qdrant and Lance already exist in this space, and I'd bet on that category eating more Python-only implementations one benchmark post at a time.

What won't move:

Anything where the value is the library ecosystem itself, not the runtime speed of any single call. Web frameworks, ORMs, data science notebooks, the huge tail of internal glue scripts that run once a day and don't care if they take 200 milliseconds or 2 milliseconds. Rewriting those in Rust would trade away exactly the thing Python was good for, without buying back anything a user would notice.

Here's my prediction:

Within the next two years, expect at least one more widely used Python library (a vector search library or an embeddings preprocessor is the likely candidate) to quietly ship a Rust core the same way pydantic and orjson did, announced with the same kind of before-and-after benchmark chart. And expect FastAPI, or whatever wins the next round of AI backend frameworks, to still be pure Python five years from now, because nobody has ever chosen a web framework for how fast it parses a single request.

The language people write in day to day and the language doing the real work underneath are already two different things. That gap is going to keep widening, and it's worth watching which side of it your own code ends up on.