Python Never Needed Saving. It Needed Company.

Mojo, Rust, and the rest aren't replacing AI's slowest language. They're just filling the gaps it was never built to close.

By Matteo Ricci

AI Systems & Developer Tools Analyst

Last Updated: June 14, 2026

Reading Time: 11 min read

In 2024, tech media was flooded with headlines like “Python Is Dead” and “Mojo Will Rule AI.” By 2026, Python’s share in the TIOBE Index fluctuated between 20.97% and 21.81%, and in July 2025 it reached a record 26.98% — the highest share any language has ever achieved in the history of the index. At the same time, Rust continued gaining ground in AI infrastructure, Mojo released its 1.0 Beta in May 2026, and Modular raised a total of $380 million at a $1.6 billion valuation.

Python did not disappear. It became more central.

That leads to a core question: if Python is really so slow, why hasn’t the AI industry abandoned it? Why has its position in the ecosystem become even more entrenched?

The answer is not about “which language is better.” It is about why “better” was never the decisive factor in the first place.

Part 1: Python was never the fastest language — and people misunderstood how it wins

Python never competed on speed. From the beginning, its strengths were readability, ecosystem size, and development velocity. In AI, those advantages were amplified into something unusual.

PyTorch’s documentation, tutorials, and community discussions are overwhelmingly Python-first. That means the entry point into AI is not “choose a language.” The ecosystem chooses Python for you. The bindings are so deeply integrated that features like torch.compile, autograd, and even CUDA kernel scheduling are exposed through Python. Replacing Python would not mean swapping syntax; it would mean rebuilding the metaprogramming layer of the framework itself.

PyTorch has more than 85,000 GitHub stars. Hugging Face hosts over a million models. Almost all of that ecosystem is Python-native.

The 2025 Stack Overflow Developer Survey showed Rust remained the most admired language for the ninth consecutive year, with roughly 72–82% of developers wanting to continue using it. Yet Python was still the most in-demand language in hiring, with 45.7% of employers looking for Python developers.

That gap — “most admired” versus “most used” — says a lot. Language choice is first an ecosystem-lock-in problem, and only second a performance problem.

Part 2: AI magnified Python’s cracks

Python’s limitations were never secret: the Global Interpreter Lock limits true parallel execution, CPU-heavy workloads can become bottlenecks, GPU control depends on external libraries, and concurrency outside I/O-heavy scenarios is mediocre.

But those problems changed shape over time.

1. In 2016, a ResNet-50 training script was usually bottlenecked by data loading.

The main pain point was I/O, not Python itself.

1. By 2020, the bottleneck had shifted to GPU utilization.

The industry had optimized data pipelines enough that GPUs became the expensive idle resource.

1. By 2024, the bottleneck was often compilation.

The first run of torch.compile could take minutes because Python’s dynamic nature makes static optimization extremely difficult.

PyTorch core developer Edward Yang wrote in 2025 that adoption of torch.compile for training lagged far behind inference. Training workflows cannot tolerate a five-minute pause at the start of the first epoch. Python’s flexibility became expensive once compilers tried to reason about it.

In April 2026, Python 3.14 promoted its free-threaded build from “experimental” to “supported,” but the default interpreter still kept the GIL. Enabling free-threading reduced single-thread performance by roughly 5–10%, and only about half of C extensions were compatible.

Python spent 33 years “solving” the GIL by making it optional — and accepting tradeoffs in compatibility and performance.

Part 3: Rust, Mojo, and Triton are not filling the same gap

Rust: the infrastructure gap

Rust’s rise in AI is additive, not replacement-driven. Projects like Candle can approach PyTorch+CUDA inference performance, but the difference in developer speed is not 3%. It is often an order of magnitude.

Polars can outperform Pandas dramatically, yet teams still fall back to Pandas when they need flexible Python UDFs. Rust is not replacing Python’s modeling layer. It is replacing the things Python was never meant to own: inference backends, data pipelines, edge deployment, API gateways, schedulers, and systems software.

An important pattern is where Rust adoption starts. Teams rarely rewrite training code first. They rewrite peripheral services first — logging systems, gateways, batch schedulers — because those are operationally critical but do not require ML researchers to maintain them. Once Rust proves itself there, it moves inward toward core inference logic.

Mojo: the performance gap — at the cost of ecosystem

Mojo entered 1.0 Beta in May 2026, and Modular said a final 1.0 release would follow in the coming months. Its headline claim of “68,000× speedups” came from a Mandelbrot benchmark — an extremely parallel workload.

Real AI workloads are very different. Speedups there are more commonly in the range of 10× to 1,000×, and they depend heavily on the scenario.

Mojo also still lacks many features Python developers consider basic: lambda expressions, list comprehensions, generators, and pattern matching. More importantly, it still lacks a mature native compiler and standard library experience; development is largely tied to Mojo Playground or the MAX platform.

That means the “Python superset” promise is currently more syntactic than operational. You can import Python modules, but you are still operating inside Modular’s runtime world.

Mojo 1.0 Beta introduced major breaking changes: fn was removed in favor of def, UnsafePointer was redesigned as non-null, and negative indexing support was removed. Those are signs of a language still settling its foundations.

Modular’s $250 million funding round in 2025 brought total funding to $380 million, but funding and developer adoption are not the same thing. The real commercial value may lie more in the MAX compute platform than in Mojo as a general-purpose language.

How you can define and train a deep learning model with Mojo

Triton: the forgotten “fourth language”

Triton may be the most underestimated player in this story. Since PyTorch 2.0, torch.compile has generated Triton kernels by default. FlashAttention 2 and 3 use Triton for Hopper-class GPUs.

Triton lowers the barrier to CUDA development — but it also introduces a different kind of difficulty: debugging.

A kernel can run correctly while being 5× slower than expected because of register spilling, block-size choices, or warp configuration, and the tooling often gives little guidance. Developers describe Triton not as hard to learn, but hard to diagnose.

Its real strategic advantage is subtler: Triton never tried to replace Python. It disguised itself as Python. Kernels are written as Python-like functions decorated with Triton annotations, which lets it inherit Python’s ecosystem instead of fighting it.

Part 4: The emerging three-layer AI stack

By 2026, AI systems are naturally converging toward a layered architecture:

1. Research layer: Python

For notebooks, experiments, and model validation. A researcher can move from idea to prototype in hours because the entire knowledge ecosystem is already Python-first.

1. Performance layer: Mojo / Triton / CUDA

For kernel optimization, compilation, and GPU saturation. Increasingly, this layer is becoming invisible: developers trigger optimizations through tools like torch.compile without directly writing Triton.

1. Infrastructure layer: Rust

For inference services, gateways, schedulers, and operational systems where memory safety and concurrency matter more than experimentation speed.

The key insight is that the question is no longer “Which language should we choose?” It is “Which language belongs in which layer?”

These choices are local optimizations accumulated over years of trial and error, not a grand unified architecture plan.

Part 5: AI code generation is strengthening Python’s lock-in

A 2025 academic study (arXiv:2503.17181) evaluated eight major LLMs and found something striking: when solving language-agnostic problems, the models chose Python in roughly 90–97% of cases.

Even when generating initial project code where Python was not the best fit, Python still dominated with about 58% share.

The study included models such as GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, DeepSeek-V3, and Qwen 2.5. The consistency across models suggests this is not a quirk of one system; it is a property of the training data distribution.

That changes the economics of language adoption.

An engineer using an AI coding assistant may want Rust, but if the generated Rust code repeatedly trips over borrow-checker issues while the Python version runs immediately, the friction pushes the decision toward Python. Not because Python is superior in theory, but because the toolchain makes it cheaper in practice.

LLMs themselves are becoming ecosystem gatekeepers.

Part 6: What happened to projects that tried to “replace Python”?

Over the last decade, “Python replacement” projects have tended to end up in one of three places:

1. They became Python extensions.

Numba, Cython, and Triton succeeded by making Python faster from within, not by pulling developers away from it.

1. They retreated into niches.

Julia found a place in scientific computing, but never became a dominant AI infrastructure language because the broader ecosystem remained Python-centered.

1. They are still trying — but the road is longer than expected.

Mojo’s original roadmap targeted general availability much earlier than reality delivered. Chris Lattner’s earlier success with Swift is instructive here: Swift was technically strong, but ultimately became tightly bound to Apple’s ecosystem. Mojo’s “Python superset” strategy echoes Swift’s “Objective-C compatibility” strategy — reduce migration pain while the original ecosystem keeps most of the gravity.

Developers are not really choosing languages. They are choosing the cost of exiting an ecosystem.

A team will often tolerate a 20% performance penalty rather than an 80% ecosystem penalty, because ecosystem losses hit the whole organization while performance losses can often be mitigated with hardware, optimization, or selective rewrites.

Part 7: The prediction mistake the tech industry keeps making

The industry loves replacement narratives: Linux will replace C, Java will replace C++, JavaScript will replace Java, GPUs will replace CPUs.

Reality is usually messier. New technologies become complements before they become substitutes — and often they never fully become substitutes at all.

C did not disappear. It became the universal systems layer. C++ concentrated in performance-critical paths. Java became the default backend language for many enterprises. GPUs did not kill CPUs; they made CPUs more specialized.

Python is going through the same transition.

Rust and Mojo are not weakening Python. They are freeing it from responsibilities it was never designed to carry: memory safety, high-concurrency services, low-level GPU kernels, and systems programming.

Python can become what it is unusually good at: coordination, experimentation, orchestration, and rapid iteration.

Python 3.14’s optional free-threading model illustrates the language’s philosophy perfectly: evolve without breaking the ecosystem. That philosophy makes Python slower than many modern languages, but it also makes it a remarkably stable coordination layer.

Conclusion: Python is becoming AI’s coordination layer

The most successful AI teams in the next few years probably will not bet on a single language. They will coordinate with Python, support systems with Rust, accelerate hot paths with Mojo or Triton, and squeeze hardware through CUDA.

The winner is not one language. It is the team that knows where each language belongs.

This emerging three-layer stack is not the perfect solution. It is the least bad solution — and in engineering, the least bad solution is often the one that survives longest.

Python never needed saving. It just needed partners willing to handle the work it was never meant to do alone.

References

1. Modular. (2026, May 7). Mojo 1.0 Beta: The next chapter for Mojo. Modular Blog. https://www.modular.com/blog/mojo-1-0-beta

2. Shafiq, M. I., et al. (2025). LLMs love Python: A study of LLMs' bias for programming languages and libraries. arXiv preprint arXiv:2503.17181. https://arxiv.org/abs/2503.17181

3. Stack Overflow. (2025). Stack Overflow Developer Survey 2025. https://survey.stackoverflow.co/2025/

4. TIOBE Software. (2026). TIOBE Programming Community Index. https://www.tiobe.com/tiobe-index/

5. Tillet, P., et al. (2025). TritonForge: Automated GPU kernel optimization via programming language modeling. Proceedings of the 42nd International Conference on Machine Learning (ICML 2025). https://arxiv.org/abs/2505.21056

6. Yang, E. (2025, August 15). The state of PyTorch compile for training. PyTorch Developer Discussions. https://dev-discuss.pytorch.org/t/the-state-of-pytorch-compile-for-training/2726

7. Python Software Foundation. (2026, April). What's new in Python 3.14: Free-threaded CPython. Python Documentation. https://docs.python.org/3.14/whatsnew/3.14.html

Matteo Ricci

AI Systems & Developer Tools Analyst

Matteo Ricci covers developer tools, AI-assisted software engineering, and the evolving relationship between automation and human expertise. His writing often examines the gap between technological promises and operational reality.