上周二，我为一个小型的推荐系统项目创建了一个虚拟环境。这个项目并不复杂。

我使用了 Pydantic 来定义模型，用 Polars 处理数据，用 orjson 处理网络通信，用 ruff 在提交代码前做检查，并用 uv 来管理整个环境。

安装过程只花了三秒钟。然后，我在那里愣了足足一分钟，因为我突然意识到一件事。

我意识到，我刚刚安装的这些工具，几乎没有一个是真正用 Python 写的。

• Pydantic 第 2 版的核心由 Rust 编写，仅提供 Python 接口。
• Polars 完全由 Rust 编写。
• orjson 完全由 Rust 编写。
• ruff 完全由 Rust 编写。
• uv 完全由 Rust 编写。

真正会以 Python 运行的，只有我接下来要写的业务代码。而所有干重活的底层，都是用另一种语言编译好的程序，只是打包成了包文件交给我使用。

这并不是什么新鲜事。早在我在学校读书时，NumPy 就已经在使用 Fortran 和 C 了。

Scikit-learn 是 Python 和 Cython 的混合体。TensorFlow 拥有 C++ 引擎和 Python 控制系统。

一直以来，Python 都是一门“借力”的语言——只要速度足够快、足够好用，它就会让其他语言去干苦力活。真正发生改变的，是 Python 究竟在“借用”哪种语言。

JetBrains 2025 年 Python 开发者调查问卷覆盖了超过 3 万名受访者。在调查结果深处，藏着这样一行字：Rust 在 Python 二进制扩展中的使用率，在短短一年内从 27% 飙升至 33%。

十二个月内增长了 6 个百分点。对于一个稳定的生态系统而言，这是一个巨大的飞跃，而 Python 二进制扩展绝对是科技界最稳定的生态之一。

Python 语言峰会对此有着更直白的表述：在所有上传到 PyPI 且包含原生代码的新项目中，有四分之一到三分之一从零开始就使用了 Rust。

这意味着它们完全基于 Rust 构建，而不仅仅是使用部分 Rust 功能或与其他语言混合开发。

Talk Python 的负责人 Michael Kennedy 可能比任何人都更了解库开发者。他告诉受访者，Python 开发者应该学习如何看懂基本的 Rust 代码。

他并不是要求大家学会用 Rust 写代码，而是要会“读”。原因在于，Python 开发者依赖的底层库越来越多地由 Rust 编写。

因此，当 Rust 与 Python 交界处出现问题时，如果能看懂 Rust 代码在做什么，将会非常有帮助。Python 语言峰会和 Michael Kennedy 都认为，Rust 正在成为 Python 世界的一部分。他们希望 Python 开发者即使不会写 Rust，也能看懂它的逻辑。

有趣的问题不是 Rust 为什么能赢，而是 Rust 为什么能够赢。

答案只有两个词：PyO3 和 maturin。

PyO3 提供了一种方式，让你可以用 Rust 编写 Python 扩展，而无需手动触碰哪怕一行 CPython C API。maturin 则负责将其打包为 wheel 文件并发布。

这两者联手，将过去需要耗费两周时间、伴随着引用计数 bug 和凌晨两点内存崩溃的 C 语言开发噩梦，简化成了两条命令：cargo new 加上 maturin publish。

没有人为此发表过宣言。Python 软件基金会（PSF）也没有发布任何宣布全面转向 Rust 的公告。

只是工具链在不断变好，而库作者们逐渐发现：他们可以在周末用 Rust 构建新项目，并且运行速度比它所替代的 C 扩展快十倍。

这就是生态系统发生翻转的方式。不是通过公告，而是通过“启动新的原生库时，默认选择什么工具”这一共识的缓慢转移。

接下来我要说的话，可能会让那些渴望引发编程语言圣战的人感到失望。

三十年来，Python 始终扮演着“胶水语言”的角色。当人们说 Python 很慢时，这并不是真相。

真正的理由是：根本没有人用 Python 去写程序中需要高速运行的部分。他们使用 C、Fortran 或 Cython 来处理这些核心逻辑，而 Python 只负责处理那些更容易上手的外围工作。

Rust 的出现并不是在替代 Python。它仅仅是把程序中原本需要编译的部分，换了一种语言来写而已。

假设你回到 2015 年，用 Rust 重写了 NumPy 的底层部分，而不是用 C。你确实会让 NumPy 的维护者们轻松一些。但对于使用者来说，这没有任何区别。你使用 NumPy 的方式依然如故。

当你写下 import numpy as np 时，NumPy 底层是用什么语言写的根本无关紧要。你的代码不在乎，你的模型也不在乎。

那么，使用 Rust 到底带来了什么？你并没有让最终用户的程序运行得更快，因为需要编译的部分早就编译好了。

你得到的是：NumPy 的开发者们更开心了，程序的内存管理更安全了，构建速度更快了，添加新功能也更容易了。

这些好处全都是针对库开发者的，而不是针对终端用户的。

Python 并没有被替代。Python 底下的编译层正在从 C 切换到 Rust，而真正有趣的问题是：这个外层包装（Wrapper）是否还有足够的价值来证明其存在的意义。

如果你从未为 CPython 编写过 C 扩展，建议你试一次。然后，你就再也不会想写第二次了。这基本上就是接触过这套东西的人的真实心态。

以前编写 C 扩展的方式真的非常痛苦。你必须为你使用的每一个 Python 对象考虑引用计数。

一旦弄错，要么造成内存泄漏，要么导致程序崩溃。在很长一段时间里，这简直是一场灾难。而且，还要为每个 Python 版本和每个平台制作 wheel 文件，这本身就是一项繁重的工作。

如果你负责维护一个 C 扩展，你会把所有时间都花在维护上，根本无暇顾及库本身的功能开发。

后来 PyO3 出现了。它将所有复杂的细节都隐藏在 Rust 的所有权模型背后。Cargo 接管了构建部分，maturin 接管了 wheel 打包部分。过去需要六周才能搭建好的流程，现在只需一个周六下午就能搞定。

这也是 TypeScript 在浏览器开发中大受欢迎，Kotlin 在 Android 开发中流行起来的原因。

并不是因为旧语言不好，而是新语言把那些枯燥繁琐的部分变得简单了。写库的人也是普通人，他们更喜欢按部就班地开发，而不是去处理令人头疼的麻烦。

如果你是一名使用 Python 编写应用代码的开发者，并且不涉及 C 扩展的开发，那么这一切对你来说没有任何改变。

你 import 的东西看起来还是一样的，你调用 API 的方式也完全一样。当你执行 pip install polars 和 pip install pandas 时，这两个命令在底层安装了不同语言编写的组件，但你的代码对此一无所知，也毫不关心。

如果你负责维护系统底层的扩展，那么你在新项目中的技术选型其实已经发生了改变。没有人逼你重写现有的代码，但现实是，新项目默认会使用一种新的工具，那就是 Rust。

如果你正打算重写扩展以支持多线程，那么你必须决定使用哪种语言来进行重写。

如果你去那些做系统软件的公司面试 Python 岗位，那么了解 Rust 现在已经是一项必备技能了。

你不需要会用它写代码，但你必须能看懂它。面试官考察的不是你能否从零开始用 Rust 搭建项目，而是你能否理解程序在跨越 Rust 和 Python 边界时到底发生了什么。

如果你在 Medium 上写关于 Python 的文章，你可能会花更多时间去科普基础概念，而减少对高阶特性的讨论。抱歉，现实就是如此。

接下来要谈的是自由线程，这才是那个打破客套话术的焦点。

Python 3.14 正式发布了对自由线程构建的支持。PEP 703 落地了。全局解释器锁（GIL）现在是可选的，而不再是实验性的。听起来很棒，对吧？

但问题是，如果你依赖的 C 扩展不具备线程安全性，那么你的 CPython 即使摆脱了 GIL 也毫无用处。因为在一个自由线程的解释器中导入一个非线程安全的扩展，会悄无声息地重新启用 GIL，让你陷入两头不讨好的最差局面。

将过去十年积累的 C 扩展改造为线程安全，是一项极其庞大的无偿维护工作。相比之下，用 Rust 重写它们往往比改造更快，因为 Rust 的所有权模型在编译阶段就帮你完成了一半的线程安全分析。

因此，用 Rust 重写绝不仅仅是一种审美偏好。它们才是真正为自由线程 Python 在实际工作负载中扫清障碍的关键。

每一个发布且具备完善线程安全性的 Rust 库，都是在为 CPython 3.14 铺路，让自由线程在生产环境中真正可用。

这不是什么适合放在 PPT 里的漂亮话，但这正是正在发生的客观事实。

Python 没问题。使用 Python 的人数依然在持续增长。Python 非常易用，这就是它如此受欢迎的原因。一项 3 万人的调查显示，86% 的人将 Python 作为他们的主要语言。

当你审视 Python 中那些需要追求极致性能的部分时，它其实已经不再是 Python 了。它更像是披着 Python 外衣的 Rust。而且，这种情况每年都在愈演愈烈。

如果你愿意，你可以把这视为一个危机。但我并不这么认为。我觉得这正是 Python 一直以来的运作方式。

当你想不纠结底层细节、快速编写代码时，你使用 Python；当你需要代码跑得飞快时，你使用其他语言。唯一改变的，只是那个“其他语言”到底是什么。

以前，人们需要速度时会选择 C。现在，他们选择 Rust。

五年后，他们依然会使用 Rust。而你现在写的 Python 代码，看起来会和多年前写的 Python 代码没什么两样。这就是真相，也是为什么实际上没有人真正对此感到恐慌的原因。

你真正应该关注的人，不是那些就此事发表长篇大论的人，而是那些默默用 Rust 构建库的开发者。

他们选择 Rust 仅仅是因为这样更简单，甚至做完之后他们都不屑于去炫耀。

这也是你判断这场变革确确实实正在发生的方式。