Original Analysis: Why Python Monopolizes LLM Development—Ecosystem Flywheel and Data Evidence

Copyright Notice and Disclaimer Copyright notice and disclaimer can be found in Part 1 of the series.

Original References

• Stack Overflow Developer Survey 2025: https://survey.stackoverflow.co/2025/
• PEP 703 – Making the Global Interpreter Lock Optional: https://peps.python.org/pep-0703/
• The runtime behind production deep agents — LangChain: https://www.langchain.com/blog/runtime-behind-production-deep-agents

Original Nature This article is an original comprehensive interpretation based on multi-source materials, focusing on establishing the ecosystem flywheel analytical framework to explain the causes of Python’s dominance.

Opening: Looking at Multi-Source Data Together

First, look at this data:

Data Note: The following data comes from Stack Overflow Developer Survey 2025 (published in May 2025, reflecting 2024 developer survey results). This article was written in April 2026.

Stack Overflow Developer Survey 2025

• Python usage rate: 48.2% (4th place)
• Annual growth: +3.2%
• Docker usage rate: 57.2% (+8%)
• AI developers using AI tools: 72%

Now look at this testimony:

Zachary DeVito (PyTorch Core Dev, Meta AI)

“At PyTorch, Python is typically used to orchestrate about 8 GPUs and 64 CPU threads, growing to 4,000 GPUs and 32,000 CPU threads for large models. We often end up replacing one process with 72 processes just because of the GIL.”

Now look at this product:

LangChain Deep Agents Runtime

• Durable execution
• Memory (short-term checkpoint + long-term store)
• MCP/A2A protocols (open Agent interconnection)
• MIT License, no vendor lock-in

Three sources, three angles:

• Data: Python is growing, ecosystem expanding
• Testimony: Python is a bottleneck, but irreplaceable
• Product: Python ecosystem is defining AI infrastructure

Question: Why are these three things all happening in Python? Why does Python monopolize LLM development?

Material A: Stack Overflow Data—Quantitative Evidence of Language Ecosystem

Python’s Growth Rate: Sustained Growth Trend

Python has been growing for over 10 consecutive years. At a high base of 48.2%, it still achieves a +3.2% leap—this is unusual.

Compare with other Top 5 languages:

Language	Usage Rate	Annual Change
JavaScript	63.6%	Stable
HTML/CSS	55.8%	Stable
SQL	52.1%	Stable
Python	48.2%	+3.2%
Java	28.2%	Stable

Python is the only language with significant growth.

AI Driving Force

Stack Overflow’s data interpretation: “This illustrates Python’s ability as the preferred language for AI, data science, and backend development.”

Over a decade of continuous growth means: Python’s dominance in AI/data science is self-reinforcing—more talent → richer libraries → attracting more talent.

Toolchain Ecosystem Synergy

Tool	Usage Rate	Annual Change	AI Association
Docker	57.2%	+8%	LLM deployment standard
Pip	35.2%	-	Python package management infrastructure
Kubernetes	22.5%	-	LLM service orchestration
Redis	21.8%	+5%	Vector cache, conversation history

Docker’s +8% is significant single-year growth. Docker + Python + LLM is the golden combination:

• Environment isolation (CUDA/PyTorch version dependencies)
• Training-inference environment consistency
• Multi-modal model dependency complexity management

Web Framework Landscape

Framework	Usage Rate	Annual Change
FastAPI	12.1%	+3%
Flask	14.2%	Stable
Django	12.8%	Stable

FastAPI’s rise (see Part 5) is highly correlated with the LLM API service trend. OpenAI API, Hugging Face, and LangChain all rely on high-performance Python API frameworks.

Material B: PEP 703 Testimony—Real Industry Dilemmas

PyTorch’s Scaling Problem

Current State:

• Orchestrate 8 GPUs and 64 CPU threads
• Target: 4,000 GPUs, 32,000 CPU threads
• Reality: 72 processes replace 1 process

72 Processes vs 1 Process

Why can’t we use 1 process with 72 threads?

Because of the GIL. Python threads are serial at the interpreter level (see Part 3). True parallelism requires multi-process, but multi-process has costs:

• High process creation overhead
• High memory usage (each process has a copy of the interpreter)
• CUDA contexts cannot be shared
• High inter-process communication costs

Zachary’s Testimony

“On three different occasions, I spent an order of magnitude more time working around the limitations of the GIL than solving the actual problem.”

This is not a complaint. This is evidence that Python has become a bottleneck.

DeepMind’s Practice

Manuel Kroiss’s testimony:

“At DeepMind, we often have to fight with the Python GIL. In many applications, we want to run 50-100 threads per process. However, the GIL often becomes a bottleneck even with fewer than 10 threads.”

DeepMind’s response: “To deal with the GIL, we usually end up rewriting most of the Python code in C++.”

Cost: Reduced code accessibility (Python → C++), decreased iteration speed.

scikit-learn’s Engineering Burden

Olivier Grisel’s testimony:

“For years, scikit-learn developers have maintained auxiliary libraries like joblib and loky, trying to work around some limitations of multi-processing. If we could use multi-threading without contention, this extra work and complexity wouldn’t be necessary.”

This is ecosystem-level engineering burden—because of GIL, the entire ecosystem has to invent workarounds.

Material C: LangChain Ecosystem—Definers of Infrastructure

Deep Agents Runtime Capabilities

LangChain is defining the infrastructure for production-grade Agents:

Capability	Description
Durable execution	Checkpoint persistence, Agents can pause/resume
Memory	Short-term (within thread) + long-term (cross-thread)
Multi-tenancy	Auth/AuthZ/RBAC
Human-in-the-loop	interrupt/resume mechanism
Streaming	Real-time response stream
Sandbox	Code execution isolation
MCP/A2A	Open protocols connecting Agents

These are not theoretical concepts. These are runtime capabilities required in production environments.

Sleep-time Compute

A new concept proposed by LangChain:

“Sleep-time compute: Agents doing useful work during idle time, allowing users to benefit from accumulated thinking rather than on-demand latency.”

Examples:

• Night research Agent (crawling new papers every night)
• Morning preparation Agent (checking calendar, drafting briefs)
• Monitoring Agent (regularly checking system health)

These scenarios require long-running Python processes—the GIL bottleneck is more prominent here.

Open Protocols and MIT License

LangChain’s choices:

• MIT License: No vendor lock-in
• AGENTS.md: Open standard
• MCP/A2A: Open protocols

This is not a business strategy. This is an ecosystem strategy—gaining wide adoption through openness.

The Real Divide Is Not Technical Merit, But Ecosystem Flywheel

Figure 1: Python’s dominance in AI is driven by the flywheel effect of talent-libraries-applications-investment

Quantitative Analysis of the Ecosystem Flywheel

To verify the existence of the ecosystem flywheel, qualitative description alone is insufficient. The following data from multiple verifiable public sources demonstrates the cumulative effect of Python’s ecosystem between 2010-2024.

PyPI Package Growth Curve (2010-2024)

Year	PyPI Packages	Annual Growth	AI/ML Related %
2010	10,000	-	< 1%
2015	75,000	+650%	~3%
2018	175,000	+133%	~8%
2020	280,000	+60%	~12%
2022	420,000	+50%	~18%
2024	580,000+	+38%	~25%

Data sources: PyPI official statistics, Google BigQuery Python package analysis reports

PyPI packages grew from approximately 10,000 in 2010 to over 580,000 in 2024—a nearly 60-fold increase in 14 years. More significantly, the proportion of AI/ML related packages rose from less than 1% to approximately 25%, indicating a structural shift in Python’s ecosystem growth driver—from general-purpose programming language to AI infrastructure.

GitHub AI Project Language Distribution (2024)

GitHub’s 2024 annual report shows that among repositories tagged as “machine-learning” or “artificial-intelligence”:

Language	Project Share	Star Growth Trend
Python	68.4%	+42%
Jupyter Notebook	12.1%	+38%
JavaScript	6.2%	+15%
C++	4.8%	+22%
R	3.1%	+8%
Other	5.4%	-

Data source: GitHub Octoverse 2024 Report

Python dominates AI open-source projects with an absolute 68.4% share. Notably, Jupyter Notebook (essentially Python’s frontend) alone accounts for 12.1%, bringing the combined total to over 80%. This means that 4 out of 5 AI open-source projects are based on the Python ecosystem.

Job Market Python Demand Trends

According to LinkedIn and Indeed annual skills reports:

Year	AI/ML Jobs Mentioning Python	Change from Previous Year
2018	62%	Baseline
2020	71%	+9%
2022	78%	+7%
2024	83%	+5%

Data sources: LinkedIn Emerging Jobs Report, Indeed Hiring Lab

Python penetration in AI/ML hiring rose from 62% in 2018 to 83% in 2024. This trend shows diminishing marginal returns but continues upward—indicating the market has entered a “Python by default” phase, where Python has shifted from competitive advantage to entry barrier.

Academic Paper Language Statistics

Analysis of code links in arXiv cs.LG (Machine Learning) and cs.AI (Artificial Intelligence) papers from 2018-2024:

Language	Open Source Code Link %	GitHub Reference %
Python	89.3%	91.2%
C++	4.1%	3.8%
Julia	2.8%	2.1%
R	1.5%	1.4%
Other/Unlabeled	2.3%	1.5%

Data sources: Papers with Code 2024 Annual Report, arXiv API metadata analysis

Academia is the source of AI innovation. Nearly 90% of machine learning papers include Python code, which means: new algorithms default to Python for paper-to-implementation; reproduction costs are lowest in the Python ecosystem; knowledge spreads through Python code.

Quantitative Proof of Flywheel Effect

The four datasets above can be summarized as four gears of the flywheel:

PyPI Package Growth ← → GitHub Project Explosion
       ↑                       ↓
Academic Paper Standardization ← → Job Market Confirmation

• Talent Gear: 83% Python demand in the job market sends a clear signal to talent supply, guiding more learners to choose Python
• Library/Framework Gear: 580,000+ PyPI packages create network effects—each new package enhances the value of the entire ecosystem
• Application Gear: 68.4% GitHub project share validates widespread adoption at the application layer
• Investment Gear: 89.3% Python share in academic papers means highest ROI for knowledge production investment

Once the flywheel starts, each gear’s rotation accelerates the others. Python’s ecosystem flywheel has been spinning for over 10 years, and its inertia creates extremely high barriers to entry for any alternative language.

Three Gears of the Flywheel

PyPI Package Growth ← → GitHub Project Explosion
       ↑                       ↓
Academic Paper Standardization ← → Job Market Confirmation

• Talent Gear: 83% Python demand in the job market sends a clear signal to talent supply, guiding more learners to choose Python
• Library/Framework Gear: 580,000+ PyPI packages create network effects—each new package enhances the value of the entire ecosystem
• Application Gear: 68.4% GitHub project share validates widespread adoption at the application layer
• Investment Gear: 89.3% Python share in academic papers means highest ROI for knowledge production investment

Once the flywheel starts, each gear’s rotation accelerates the others. Python’s ecosystem flywheel has been spinning for over 10 years, and its inertia creates extremely high barriers to entry for any alternative language.

Challenges for Other Languages

Julia: Technically advanced, but ecosystem flywheel not formed

• Talent: Academic circle mainly, limited industry presence
• Libraries: Far fewer than Python
• Applications: Few production deployments

Mojo: Same goal, same dilemma

• Compatible Python syntax, but not Python
• Needs to rebuild the entire ecosystem

C++/Rust: Better performance, but lower development efficiency

• Talent: High barrier, limited numbers
• Libraries: Many low-level libraries, few high-level AI frameworks
• Applications: Inference optimization, few training frameworks

Triton (OpenAI)‘s niche: GPU kernel fusion, but ecosystem limited to inference optimization, cannot replace complete training frameworks.

ONNX Runtime: Cross-language deployment solution, but training still requires Python.

This is not a technical problem. This is an ecosystem problem.

Detailed Evaluation of Alternative Languages and Niche Scenarios

Despite Python’s dominance in the AI ecosystem, multiple emerging languages are challenging in specific domains. The following systematic evaluation of five major alternative languages is based on actual ecosystem data from 2024-2025, along with their real advantages and irreplaceable niche scenarios.

Julia: Theoretical Advantages in Scientific Computing vs. Reality Gap

Julia 1.10 (released January 2024) indeed has technical highlights in numerical computing: native automatic differentiation support (Zygote.jl), LLVM compilation optimization achieving near-C performance, symbolic computation capabilities (Symbolics.jl) excelling in differential equation solving. According to JuliaHub’s 2024 report, Julia’s adoption in academic institutions continues to grow, with computational science courses at MIT, Stanford, and other universities beginning to adopt Julia as a teaching language.

However, ecosystem shortcomings are equally apparent: Julia’s package registry (General Registry) has approximately 11,000 packages (as of April 2025), less than 2% of PyPI. In AI/ML, Flux.jl has about 4,000 GitHub stars compared to PyTorch’s 85,000+. For production deployment, Julia’s compile-time latency (TTFP, Time to First Plot) remains a pain point. While PackageCompiler can improve this, it adds deployment complexity.

Julia’s Irreplaceability: Symbolic computation and automatic differentiation in scientific computing are indeed leading. In quantum physics simulation, differential equation solving, and other fields, Julia’s symbolic computation capabilities and compilation optimization can achieve 10-100x performance over Python. But LLM ecosystem needs not just computational performance, but complete data pipelines, model repositories, experiment management—these are shortcomings of Julia’s ecosystem.

Dimension	Advantages	Disadvantages	Applicable Scenarios
Performance	LLVM compilation, near-C speed	Compilation delay (JIT)	Research prototypes, algorithm validation
Ecosystem	High-quality scientific computing packages	Limited quantity, scarce AI-specific libraries	Physics simulation, differential equations
Talent	High recognition in academia	Small job market in industry	University research projects
Deployment	Static compilation possible	Large container image size	Offline computing tasks

Mojo: 2024 Progress and Limitations

Mojo (Modular Inc.) made substantial progress in 2024. The March 2024 Mojo 24.1 release began supporting package management (Mojo Package Manager), and the October 24.5 version enhanced Python interoperability. Modular’s benchmark tests show Mojo achieving 2-5x performance over PyTorch 2.1 on specific operators (such as matrix multiplication).

But interoperability remains limited: Mojo can call Python modules (via Python.import), but data transfer requires explicit type conversion, and zero-copy sharing of NumPy arrays is not yet fully implemented. As of early 2025, Mojo’s standard library is still rapidly evolving, and Modular’s official documentation explicitly states “API unstable, not recommended for production use.”

Mojo’s Opportunity Window: Modular’s technical route is indeed worth attention. In inference optimization (such as compiling Transformers to efficient kernels), Mojo’s compile-time optimization and SIMD auto-vectorization can generate more efficient code than PyTorch JIT. By the end of 2024, Mojo has demonstrated 2-5x acceleration on specific operators. But training frameworks need distributed communication, checkpoints, mixed precision—these foundational capabilities still need time to accumulate.

Dimension	Advantages	Disadvantages	Applicable Scenarios
Performance	SIMD auto-vectorization, compile-time optimization	Only specific operators show clear optimization	Inference optimization, custom kernels
Interoperability	Python-compatible syntax	Data transfer still has overhead	Pilot projects for gradual migration
Ecosystem	Built on Modular platform	Third-party packages nearly zero	Early technology validation
Maturity	Active development	Unstable API, incomplete documentation	Experimental projects

Rust + PyO3: Emerging Hybrid Model

Rust through PyO3 (Rust-Python binding library, version 0.22 released in 2024) is becoming a performance patch for the Python ecosystem. Actual cases include: Pydantic’s core validation logic migrated from Python to Rust with 5-50x performance improvement; Ruff (Python linter) rewritten in Rust is 10-100x faster than Flake8; Polars (DataFrame library) is 2-30x faster than Pandas on specific queries.

Rust’s Rise Path: TikTok’s Vector (log collector), Cloudflare’s infrastructure prove that Rust + Python hybrid mode is maturing. PyO3 significantly reduces Rust extension development costs, and Rust Python bindings are becoming a new choice for performance-critical paths. For new performance-sensitive projects, Rust + PyO3 may be more attractive than Cython.

The risk of this model lies in development cost: Rust’s learning curve is steep, and ownership and the borrow checker pose barriers to developers accustomed to Python. Compile time is also an issue—increpmental compilation for medium-sized Rust projects may take 10-30 seconds, with full compilation reaching several minutes.

Dimension	Advantages	Disadvantages	Applicable Scenarios
Performance	Memory safety + zero-cost abstraction	Steep learning curve	Performance-critical path extensions
Safety	Compile-time memory safety guarantees	Lower development efficiency than Python	Security-sensitive infrastructure
Interoperability	Mature PyO3, low binding cost	Complex debugging (cross-language stack)	Performance optimization for existing Python projects
Ecosystem	Mature Cargo package management	Limited AI high-level libraries	Low-level operator implementation

JAX: Google’s Ecosystem Double-Edged Sword

JAX 0.4.30 (released December 2024) maintains technical advantages in function transformations (jit, grad, vmap). Google DeepMind’s internal frameworks (such as Haiku, Optax) are built on JAX, and some frontier academic research (such as diffusion models, flow matching) also prioritizes JAX implementations.

But the ecosystem gap with PyTorch is widening: In Hugging Face’s model repository, PyTorch format accounts for over 85%, while JAX/Flax is less than 5%. PyTorch 2.0’s compilation mode (torch.compile) narrows the performance gap with JAX, while the ecosystem richness advantage is clear. According to Papers with Code 2024 statistics, the proportion of new papers with PyTorch code (78%) far exceeds JAX (12%).

Dimension	Advantages	Disadvantages	Applicable Scenarios
Performance	XLA compilation, good TPU support	GPU optimization inferior to PyTorch	TPU training, academic research
Ecosystem	Heavy internal use at Google	Small open-source community	DeepMind ecosystem
Functionality	Flexible function transformations	Difficult debugging (many abstraction layers)	Cases requiring custom gradients
Deployment	SavedModel format	Immature serving toolchain	Cloud TPU inference

Triton’s GPU Kernel Fusion: OpenAI’s open-source Triton provides near-CUDA performance in specific scenarios (such as custom attention operators) but with Python-like syntax. This is a niche breakthrough for GPU programming, but cannot replace complete framework ecosystems.

ONNX Runtime’s Cross-language Deployment: Python training → ONNX export → C++/Rust/JS deployment mode is maturing. This weakens Python’s monopoly in inference, but strengthens its irreplaceability in training.

Comprehensive Evaluation Conclusion

These alternative languages are not direct competitors to Python but rather specialized tools for specific scenarios. Julia suits research prototypes, Mojo suits inference optimization exploration, Rust suits performance-critical extensions, and JAX suits the Google ecosystem and academic research. For industrial-grade LLM development, Python ecosystem completeness remains unshakable for the next 3-5 years.

Redefinition of Technical Debt

The GIL has long been seen as Python’s “technical debt,” but PEP 703 implementation redefines this concept:

• Old view: GIL is a design flaw, must be completely removed
• New view: GIL is a historical engineering trade-off, nogil is an acceptable evolution path
• Actual impact: Within 3-5 years, nogil will become mainstream, but GIL versions will still coexist

The ecosystem flywheel not only explains Python’s success, but also explains why change must be gradual—any disruptive change threatens the stability of the flywheel.

GIL Is “Technical Debt,” But Ecosystem Value Offsets the Cost

PEP 703 testimonies reveal a paradox:

• Meta, DeepMind complain about GIL
• But they still use Python
• They invest in solving GIL (Sam Gross from Meta AI)

Why?

Because the cost of GIL (multi-process complexity) is less than the cost of migrating to other languages (rebuilding ecosystem).

PEP 703’s path—not removing GIL, but making it optional—is precisely to maintain ecosystem compatibility.

Reassessment of GIL as Technical Debt: Quantifying Costs and Benefits

Real Performance Loss Estimates

Based on industry data disclosed in PEP 703, we can estimate the real performance losses caused by GIL:

Meta’s PyTorch Production Environment

• Typical scenario: 4,000 GPUs + 32,000 CPU threads
• Current solution: 72 Python processes coordinated
• Thread efficiency under GIL limitations: According to Manuel Kroiss’s testimony, DeepMind sees GIL becoming a bottleneck “with fewer than 10 threads”
• Estimated performance loss: In single-process multi-thread mode, CPU utilization may only reach 30-40%

DeepMind’s Engineering Practice “At DeepMind we often have to fight with the Python GIL…the GIL often becomes a bottleneck even with fewer than 10 threads.” This means that under ideal targets of 50-100 threads, GIL-induced parallel efficiency losses could reach 80-90%.

Hidden Costs of Multi-Process Solutions

The industry is forced to adopt multi-process as a GIL workaround, but this brings significant hidden costs:

Memory Usage: Each Python process requires an independent interpreter instance and memory space. A typical PyTorch inference process may occupy 2-4GB memory, meaning 72 processes consume 144-288GB just for process overhead.

Inter-Process Communication (IPC) Overhead: According to PyTorch distributed documentation, multi-process tensor transfers require serialization/deserialization, which may add 10-30% to training time for large model parameter synchronization.

CUDA Context Isolation: Each process requires independent CUDA context; GPU memory cannot be shared across processes, leading to reduced GPU memory utilization and context switching overhead.

PEP 703 ROI Analysis

Investors: Meta, DeepMind, scikit-learn team, Python core developers Expected Benefits:

• Simplified multi-threading programming model
• Reduced memory and IPC overhead from multi-process
• Opening true parallel computing capabilities for Python 3.13+

Key Judgment: PEP 703 is not removing GIL but making it optional (--disable-gil build). This gradual path protects ecosystem compatibility but extends the migration cycle. Expected within 3-5 years, nogil builds will become mainstream for LLM training, but GIL versions will still need long-term maintenance.

Comparison with Other Languages’ Concurrency Models

Go’s goroutine: Lightweight threads (M:N scheduling), language-level support, memory usage only 2KB initial stack. Go’s success in microservice orchestration proves this model’s effectiveness. But Go’s AI/ML ecosystem is nearly nonexistent.

Rust’s async/await: Zero-cost abstraction, compile-time safety checks, performance near C. But steep learning curve; ownership model poses barriers to data science developers.

Julia’s parallel model: Task-based parallelism (@spawn), native support for distributed array computing. Julia 1.9+ introduced more efficient thread scheduling, but ecosystem scale limits its application in LLM.

Python nogil’s future positioning: Combining C extension performance with Python’s ease of use, aiming to become the high-performance glue in “glue + core operators” mode.

Analysis of Python’s Dominance in LLM Development Stages

Training Frameworks: PyTorch vs TensorFlow vs JAX

Dimension	PyTorch	TensorFlow	JAX
GitHub Stars (2025)	85,000+	180,000+	30,000+
Paper Adoption Rate	78%	15%	12%
Enterprise Adoption	Meta, OpenAI, Hugging Face	Google, DeepMind	Google DeepMind
Dynamic Graph	Native support	TF2.x support	Functional transformations
Debugging Experience	Excellent (pdb)	Moderate	Difficult (many abstraction layers)

PyTorch’s dominance stems from its dynamic graph mechanism and Python-first design philosophy. Choices by academia and startups have formed strong ecosystem inertia.

Inference Deployment: ONNX Runtime, vLLM, TensorRT

vLLM’s Rise: Developed by UC Berkeley, vLLM achieves 2-4x throughput over Hugging Face Transformers through the PagedAttention algorithm. vLLM is entirely based on the Python ecosystem, supporting OpenAI-compatible API interfaces.

ONNX Runtime’s Cross-Language Deployment: Python training → ONNX export → multi-language inference mode is maturing. According to Microsoft data, ONNX Runtime can achieve 1.5-3x inference speed over native PyTorch on specific models.

TensorRT’s Ecosystem Limitations: NVIDIA’s TensorRT provides ultimate performance but requires specific CUDA versions and model format conversion; ecosystem generality is inferior to Python-native solutions.

Agent Frameworks: LangChain vs LlamaIndex vs AutoGen

LangChain’s Ecosystem Position: Evolving from simple prompt chaining to complete Agent Runtime (Deep Agents), LangChain has transcended the category of tool libraries to become the definer of Agent infrastructure.

LlamaIndex’s Focus: Focused on RAG (Retrieval-Augmented Generation) scenarios, forming a complementary rather than competitive relationship with LangChain.

AutoGen’s Multi-Agent Conversation: Microsoft Research’s AutoGen focuses on multi-Agent collaboration scenarios, showing advantages in specific enterprise workflow automation.

Commonality of all three: Entirely based on Python ecosystem; interoperability achieved through Python interfaces.

Data Engineering: Pandas vs Polars vs DuckDB

Library	Design Language	Performance Comparison	Applicable Scenarios
Pandas	Python/Cython	Baseline	General data manipulation
Polars	Rust	10-100x	Large-scale data queries
DuckDB	C++	5-50x	Embedded analytical database

Polars’ Challenge: Although Polars is 10-100x faster than Pandas on specific queries, Pandas’ API ecosystem (integration with scikit-learn, Matplotlib, Plotly) makes it difficult to replace in the data science ecosystem.

DuckDB’s Opportunity: As an embedded OLAP database, DuckDB performs excellently in local big data processing, with extremely low integration cost with Python (pip install duckdb).

Python’s dominance in the data engineering chain stems from historical accumulation and ecosystem interlocking—every tool in every stage assumes you are already using Python.

Counter-Perspectives on Ecosystem Risks: Hidden Concerns Behind Prosperity

Single-Point Dependency Risk: Python Software Foundation Funding Status

Python language development relies on Python Software Foundation (PSF) funding. According to the PSF 2024 annual report, foundation revenue is approximately $4.5 million, expenses approximately $4.2 million, with narrow operating margin.

Key Risk: Core infrastructure (PyPI, documentation, CI/CD) maintenance funding primarily comes from corporate sponsorship (Google, Meta, Microsoft). If corporate strategies shift, Python ecosystem infrastructure may face funding gaps.

Core Developer Aging Problem

According to the Python developer survey (2024):

• Median age of Python core developers: 48
• Average annual growth of new core developers: <5 people
• Total active core developers: approximately 100

This is an “aging” developer group. New feature development and maintenance face human resource bottlenecks.

Criticism of Slow Language Evolution

Type System Lag: Python 3.5 introduced typing, but type checking remains optional. Compared to TypeScript’s rapid adoption in the JavaScript ecosystem, Python’s type system evolution appears conservative.

Slow Performance Improvements: From Python 3.8 to 3.12, pure Python code performance improved by about 10-15%, far below the promises of emerging languages like Julia and Mojo.

Conservative Syntax Innovation: Pattern matching (match/case) was only introduced in Python 3.10, many years after Scala and Rust.

Potential Impact of Corporate Funding on Ecosystem Direction

Behind PEP 703: Sam Gross is from Meta AI, the main developer of nogil. Meta’s investment in Python reflects its strategic needs for the PyTorch ecosystem.

Google’s JAX vs PyTorch: Google promotes JAX development through DeepMind, attempting to establish competition with PyTorch in the academic frontier. This corporate ecosystem competition may lead to resource fragmentation.

Risk Assessment: Python ecosystem’s “Benevolent Dictator For Life” (BDFL) mode transitioned to a governance committee model after Guido’s retirement, potentially further increasing corporate influence. Attention is needed to balance interests in the PEP decision-making process.

If We Juxtapose These Materials, We See

Python Monopoly Is Not Due to Most Advanced Technology

Python is not optimal in:

• Performance: C++/Rust is faster
• Concurrency: Go/Erlang is better
• Type safety: Rust/Haskell is stronger

But Python is the most balanced:

• High enough development efficiency
• Good enough performance (via binding C/C++/CUDA)
• Richest ecosystem

Challenge for Other Languages: Need to Rebuild the Entire Flywheel

To replace Python, need to simultaneously push three gears:

1. Attract large numbers of developers
2. Create rich library ecosystem
3. Gain widespread industry adoption

This takes time and investment. In the fast-moving AI era, there is no time to rebuild.

PEP 703’s Solution Path: Not Removing GIL, But Making It Optional

Python’s strategy:

• Default keeps GIL (backward compatible)
• --disable-gil build optional
• Ecosystem gradually adapts

This is gradual migration—not revolution, but evolution.

My Conclusion

Python’s Moat Is Not the Language, But the Ecosystem

Language features can be copied. Ecosystem flywheel cannot be copied.

Python’s dominance is unshakable in the short term (3-5 years).

Newcomers: Learning Python Is Still Highest ROI

Whether your goal is LLM research, AI engineering, or data science—Python is the highest return choice.

Not because Python is the best, but because Python’s ecosystem is the most mature.

Senior Developers: Pay Attention to PEP 703 and nogil

Python 3.13+ nogil builds are the future direction. Gradually adapt code, prepare for the free-threading world.

Architects: Evaluate Feasibility of Multi-language Hybrid

• Python: Orchestration, prototyping, rapid iteration
• C++/Rust: Performance-critical paths
• CUDA: GPU computing

Python as glue, connecting high-performance components.

What This Means for Practice

Team Technology Selection

Scenarios to Choose Python:

• Need rapid prototyping and iteration
• Depend on rich AI/ML libraries
• Team Python skills mature

Scenarios to Consider Other Languages:

• Pure inference services (C++/Rust + ONNX)
• Extreme performance requirements (kernel optimization)
• Specific domains (Julia scientific computing)

Personal Skill Development

Core Skills:

• Python fundamentals (memory, GC, GIL)
• Type annotations + async I/O
• Binding tools (Cython, PyBind11)

Advanced Skills:

• C++ (read PyTorch source code)
• CUDA (GPU optimization)
• Mojo (future possibility)

Ecosystem Participation

• Contribute to open source libraries (PyTorch, Transformers, LangChain)
• Participate in PEP discussions
• Share knowledge and best practices

Conclusion: The Flywheel Continues to Turn

Python’s dominance in AI was not designed, but turned by the flywheel.

It began with NumPy in 2006, accelerated with the deep learning boom in 2012, consolidated with PyTorch in 2016, and expanded with LLMs in 2022.

At each stage, the three gears of the flywheel (talent, libraries, applications) are accelerating.

PEP 703 is not Python’s endpoint. It is Python’s new starting point in the AI era—liberated from GIL limitations, embracing true parallelism.

In the next article, we will turn to a personal perspective: In an era where 72% of AI developers use AI tools, how should Python developers position themselves?

---

References and Acknowledgments

• Stack Overflow Developer Survey 2025: https://survey.stackoverflow.co/2025/
• PEP 703 – Making the Global Interpreter Lock Optional: https://peps.python.org/pep-0703/
• The runtime behind production deep agents — LangChain: https://www.langchain.com/blog/runtime-behind-production-deep-agents
• Python History and Development — Python.org