“Go away, Python”? Where dropping it helps - and where it doesn’t

“Go away, Python” tends to surface when teams hit performance ceilings, cold-start pain, or packaging fatigue. What’s notable here is the emergent pattern, not a wholesale exodus: CPU-bound or latency-critical paths are increasingly moving to Rust or Go, while Python remains the glue at the edges. Under the hood, the ecosystem has quietly adapted to this reality. PyO3/maturin make FFI practical, Pydantic v2’s Rust core shows the payoff of hybrid designs, and faster tooling like uv trims install times and dependency churn. Meanwhile, CPython 3.11+ brings real speedups, and no-GIL work landing behind flags in 3.13 indicates the runtime is addressing concurrency head-on.

The bigger picture is a polyglot stack that assigns the right job to the right layer: Go for lean services and fan-out concurrency, Rust for hot loops and safety at the systems edge, Python for orchestration, data workflows, and the ML interface where the heavy lifting already lives in C/CUDA. Worth noting: “rewrite it” is often costlier than profiling and isolating hotspots, and drop-in library parity across languages remains uneven. The industry implication isn’t Python disappearing; it’s tighter contracts between layers, better FFI ergonomics, and a healthier separation of concerns. “Go away, Python” isn’t a strategy - it’s a signal to re-architect thoughtfully.