Every few years, someone writes the "Python is too slow" article. It gets shared widely. The comments fill up with people suggesting Go, Rust, or whatever language had a good conference keynote that quarter. Then nothing changes. Python's market share grows. The TIOBE index ticks upward. GitHub surveys confirm what everyone already knows. The question worth asking is why.
The Ecosystem Is the Product
Languages compete on features. Ecosystems compete on leverage. Python's advantage has never been the language itself. It's the accumulated depth of libraries, tooling, community knowledge, and integration surface that makes Python the fastest path from idea to working system.
Consider what's available without leaving the ecosystem: NumPy and pandas for data manipulation. scikit-learn for machine learning. PyTorch and TensorFlow for deep learning. FastAPI and Django for web services. Airflow and Prefect for orchestration. SQLAlchemy for database access. Boto3 for AWS. The list fills pages. Every one of these libraries has years of battle-tested production use, extensive documentation, and a deep contributor base.
This creates a compounding effect. New developers learn Python because the libraries exist. New libraries get written in Python because the developers are there. Organizations standardize on Python because hiring is easier. The cycle reinforces itself, and each year the switching cost for the ecosystem grows.
How Python Is Fixing Its Own Weaknesses
The more interesting story is how the Python ecosystem is systematically closing the gaps that critics have pointed to for years.
Package management: uv
Python's packaging story has been a legitimate pain point for over a decade. virtualenv, pip, pip-tools, poetry, pipenv, conda. Each tool solved part of the problem and introduced new friction. Dependency resolution was slow. Environment creation was slow. Reproducing environments across machines required discipline and luck.
uv changes this. Built in Rust by the Astral team, uv is a drop-in replacement for pip, pip-tools, virtualenv, and large parts of pyenv. It resolves dependencies in seconds where pip takes minutes. It creates virtual environments in milliseconds. It handles Python version management. It has a lockfile format that works.
The performance difference is dramatic. Installing a complex project's dependencies goes from a minute-long coffee break to something that finishes before you switch browser tabs. That speed matters in CI pipelines, Docker builds, and developer experience. It removes one of the most common complaints about Python development.
Code quality: Ruff
Ruff follows the same pattern. Written in Rust, it replaces flake8, isort, pyflakes, and dozens of other linting and formatting tools. It runs 10 to 100 times faster than the tools it replaces. A full lint pass on a large codebase that previously took 30 seconds now takes under a second.
Speed alone wouldn't matter if the tool were less capable. Ruff implements over 800 lint rules, auto-fixes most violations, and handles import sorting and code formatting in a single pass. It has effectively consolidated a fragmented linting ecosystem into one tool.
Performance: the Rust bridge
Python's runtime performance has always been its weakest point. The GIL limits true parallelism. Interpreted execution is orders of magnitude slower than compiled languages for CPU-bound work. These are real constraints.
The ecosystem's answer is pragmatic: write the hot paths in Rust or C, and call them from Python. PyO3 makes it straightforward to write Rust extensions that Python can import as native modules. Polars, the dataframe library written in Rust, is significantly faster than pandas for most operations. The pattern is spreading. Performance-critical libraries get rewritten in Rust with Python bindings, and the Python user never has to learn Rust.
Python 3.13 introduced an experimental free-threaded mode that removes the GIL for opt-in builds. It's early, and most C extensions need updates to be thread-safe. But the direction is clear: the core team is working on the performance ceiling, and the ecosystem is building tools to raise the floor.
Type safety: gradual typing
Python added type hints in 3.5 and has steadily improved them since. Tools like mypy and pyright catch bugs at development time that would otherwise surface in production. The key insight was making typing gradual. You don't have to annotate everything. You can add types where they matter and leave the rest dynamic.
This matters for large codebases. Teams that adopted type hints report fewer production bugs and easier refactoring. The tradeoff is more upfront annotation work, but unlike a full language migration, you adopt it incrementally. That's Python's recurring strategy: improve without forcing everyone to change at once.
What This Says About Other Languages
Python's trajectory is instructive because it challenges a common assumption: that language quality determines language dominance.
Go
Go is genuinely better than Python for many server workloads. It compiles to a single binary. It has excellent concurrency primitives. It's fast. But Go's library ecosystem for data science, machine learning, and scientific computing is thin. A team that chooses Go for an ML pipeline is rebuilding infrastructure that exists as mature, tested Python packages. The language is better for the task; the ecosystem makes it worse for the project.
Rust
Rust solves problems Python can't. Memory safety without garbage collection. Predictable performance. Zero-cost abstractions. For systems programming, embedded work, and performance-critical infrastructure, Rust is the correct choice. But Rust's learning curve is steep, and its ecosystem for application-level work (web apps, data pipelines, ML experimentation) is still young. Ironically, Rust's biggest impact on most developers may be through Python tools written in Rust: uv, Ruff, Polars, and the growing set of PyO3-powered libraries.
C#
C# is a strong, mature language with deep enterprise adoption, excellent tooling in Visual Studio, and a runtime (the modern .NET platform) that performs well. For teams already inside the Microsoft ecosystem, building Windows services, or developing with Unity, C# is a natural fit. Where it falls short is reach. The data science, ML, and DevOps ecosystems that define modern infrastructure work are overwhelmingly Python-first. ML.NET exists, but its library depth and community momentum are a fraction of PyTorch or scikit-learn. C# remains powerful within its domain, but that domain hasn't expanded into the spaces where Python is growing fastest.
JavaScript/TypeScript
TypeScript has become the dominant choice for frontend and full-stack web development. For teams whose primary workload is web applications, it makes sense to standardize on one language across the stack. TypeScript's position in data, ML, and infrastructure tooling remains marginal, though. The two ecosystems overlap less than they compete.
The general pattern
Languages that try to replace Python by being "better" at Python's use cases tend to underestimate the ecosystem moat. The successful strategy, and the one Rust is executing well, is to complement Python rather than compete with it. Build the performance layer that Python calls into. Build the tooling that makes Python developers more productive. Integrate rather than displace.
One Language Across the Entire Stack
Python's dominance extends beyond application code into infrastructure and operations:
- Infrastructure as code. Pulumi lets you define cloud resources in Python. AWS CDK supports Python. Terraform remains HCL-native, but the trend is moving toward general-purpose languages for infrastructure.
- Configuration management. Ansible is written in Python and configured in YAML, but its modules and plugins are all Python.
- Container orchestration. Kubernetes operators are increasingly written in Python using frameworks like kopf.
- Cloud SDKs. Every major cloud provider ships a first-class Python SDK (Boto3, google-cloud, azure-sdk).
This means a team that standardizes on Python can handle application code, data pipelines, ML workflows, infrastructure provisioning, and operational tooling in one language. The cognitive overhead of context-switching between languages is real, and Python minimizes it across an unusually wide surface area.
Where You Should Still Pick Something Else
Acknowledging the limits matters. Python is a poor choice in specific scenarios:
- Mobile development. Python has no meaningful presence on iOS or Android.
- Latency-critical systems. Trading engines, game loops, and real-time audio processing need predictable, sub-millisecond performance that an interpreted language can't deliver.
- Large-scale concurrent services. Go and Rust's concurrency models handle thousands of simultaneous connections more efficiently than Python's async ecosystem.
- Edge and embedded computing. Tight memory constraints and limited runtimes favor compiled languages.
These are real constraints. They're also narrow compared to the breadth of what Python handles well. Most organizations have more data pipelines, web services, automation scripts, and ML workflows than they have trading engines.
The Compounding Advantage
The reason Python keeps winning is compound interest applied to ecosystem development. Every year, the libraries get better, the tooling gets faster, the type system gets stronger, and the performance ceiling rises. Meanwhile, the cost of switching away grows because more of your stack depends on Python-ecosystem tools.
uv and Ruff are the most visible examples of this compounding. They're built by a well-funded team (Astral) that identified Python's weakest points and is systematically eliminating them using Rust. The result is a development experience that's getting faster and more reliable every quarter, without requiring Python developers to learn a new language or abandon their existing tools.
For organizations making technology bets, the implication is straightforward. Python's position is strengthening, and the ecosystem's ability to self-correct its weaknesses is accelerating. Betting against Python requires betting that some other ecosystem will build a comparable depth of libraries, tooling, and community in a timeframe that matters. That bet has been losing for twenty years.