AI时代开发者拥抱Rust的趋势、性能与挑战观察

你可能注意到了：这两年技术圈有个奇怪的风潮。好好的 Python 项目不用，偏要用 Rust 重写一遍；C++ 跑了十几年的系统，微软喊着要在 2030 年前全部干掉换 Rust；连 Python 的包管理器和代码检查工具都被 Rust 版本替代了。

这不是某个人的决定，而是一股集体冲动。它背后到底在发生什么？

蟹潮来了

先看几个数字。

TIOBE 2026 年 3 月的语言排行榜上，Rust 排第 14 位，占比 1.31%。听起来不多？但注意——它在去年这个时候也是第 14，份额只涨了 0.09%。慢是慢了点，但 Rust 的增长从来不是靠排名体现的。

真正有意思的是 Stack Overflow 开发者调查。Rust 已经连续多年被评为开发者“最想使用的语言”第一名——注意，不是“最常用”，而是“最想用”。这说明什么？大量开发者还没用上 Rust，但他们跃跃欲试。

直接看 GitHub 上发生了什么。

Ruff，一个用 Rust 写的 Python 代码检查和格式化工具，GitHub 上 46.8k 星。它比原来的 Flake8 快 10 到 100 倍，比 Black 快几十倍。关键是——它替代的不是什么冷门工具，而是 Python 社区几乎人人在用的基础设施。

uv，同样来自 Ruff 背后的 Astral 公司，用 Rust 重写了 Python 的包管理。装依赖的速度从分钟级降到秒级。很多团队已经把 pip install 换成了 uv pip install，一行命令，感受立竿见影。

类似的例子还有一长串：

原工具	Rust 替代品	提升
grep	ripgrep	10-100x 速度
find	fd	直觉化语法+更快
cat	bat	语法高亮+Git 集成
ls	lsd	图标+颜色+更快
pip	uv	10-100x 安装速度
Flake8+Black	Ruff	10-100x 检查速度
Webpack	Turbopack	700x HMR 速度

数据库大佬 Siddon Tang 在 X 上总结了一个被反复验证的公式：“找一个人人都在用的慢工具 → 用 Rust 重写 → 性能 100 倍 → 大规模采用。”他把这个叫“Astral 剧本”。

功利主义：10-100 倍的性能碾压

为什么 Rust 能做到这么快？这里需要解释一个很多人搞混的概念。

Python 的“慢”不是 Python 的错——它是解释型语言，每一行代码都要在运行时翻译成机器指令。而 Rust 是编译型语言，代码在发布前就被翻译成了机器能直接执行的指令。这就像一个现场口译员和一个提前翻译好的文档，速度不在一个量级。

但这不是 Rust 独有的优势——C、C++、Go 都能做到。Rust 真正的杀手锏是在不牺牲性能的前提下，做到了内存安全。

具体来说：

零成本抽象：Rust 允许你写高级的、像 Python 一样优雅的代码，但编译后的执行效率和手写 C 差不多。你不需要在“好写”和“跑得快”之间做选择。

没有垃圾回收：Java、Python、Go 都有垃圾回收器（GC），后台默默帮你清理内存。但 GC 带来的问题是“停顿”——程序偶尔会卡一下来回收内存，在要求极致稳定的系统里这是致命的。Rust 在编译时就决定了内存什么时候释放，运行时零开销。

极致的资源效率：

一位开发者说：“在 512MB 的 VPS 上部署一个 Rust 工具，空闲时只占 10MB 内存。这就是我们折腾底层语言的理由。”

在云时代，内存就是钱。一个 Python 服务要 512MB，Rust 只要 50MB，意味着同样一台服务器能跑 10 倍的服务，或者你可以用更便宜的机器。

而 Vercel CEO Guillermo Rauch 的判断更激进：

“AI 会帮我们把大量基础设施用 Rust 重写。我们将生活在一个安全、快速、内存高效、可预测、冷启动极快的天堂里。”他转发的是一个叫 agent-browser 的项目——用 Rust 重写后，冷启动快 1.6 倍，内存少 18 倍，安装体积小 99 倍。

安全信仰：内存安全不是可选项

如果说性能是开发者用 Rust 的“欲望”，那内存安全就是企业和政府的“刚需”。

这里要提到一个很多人不知道的事实：微软和 Google 都公开承认，他们产品中 70% 左右的安全漏洞都是内存安全问题。缓冲区溢出、悬垂指针、双重释放……这些 C/C++ 程序员打了几十年交道的 bug，在 Rust 里被编译器在编译阶段就拦住了。

Rust 通过“所有权”系统做到了这一点。简单说，每块内存在同一时刻只能被一个变量“拥有”，用完自动释放。如果代码可能出现内存问题，程序根本编译不过去。

这听起来很烦？是的。Rust 的学习曲线出了名的陡峭，新手经常和编译器“打架”几个小时。但这个代价换来的是：运行时几乎不可能出现内存安全问题。

正因如此，我们看到一些重量级的行动：

• 微软宣布计划在 2030 年前消除所有 C 和 C++ 代码，转向 Rust。Windows 内核已经开始引入 Rust 模块。
• Linux 内核从 6.1 版本开始正式支持 Rust 编写内核模块。
• Android 操作系统中 Rust 代码的比例持续上升，Google 表示新代码优先用 Rust。
• Canonical（Ubuntu 背后的公司）加入了 Rust 基金会，成为黄金会员。

当操作系统内核、手机系统、云基础设施都在向 Rust 靠拢时，这已经不是社区热潮，而是产业级的方向性选择了。

AI 加速器：用 AI 翻译 5 亿行代码

但这里有个现实问题：重写几十年的 C++ 代码，人力根本不够用。

微软有约 5 亿行 C/C++ 代码要处理。就算每个工程师每天写 1000 行，也要 5000 人干 100 天。这还没算测试、调试、集成的时间。

这时候 AI 编程工具登场了。

Claude Code、GitHub Copilot、Cursor 这些工具在代码翻译方面越来越强。把 C++ 代码丢进去，让 AI 生成对应的 Rust 代码，人工审核修改——这个流程已经不再是科幻。

当然，X 上也有人调侃这种现象：“TypeScript 写的，移植到 Python，现在又在重写成 Rust。到周五就变汇编了，没人记得为什么。”

笑话归笑话，但 AI 确实大大降低了重写的成本。以前“用 Rust 重写”是一个需要反复 ROI 计算的重大决策，现在很多团队觉得——试试看呗，反正 AI 写初稿，人来把关就行。这种由 人工智能 驱动的重写可行性，正在改变游戏规则。

这就是这一波 Rust 热潮和过去不同的地方：以前是“我想用 Rust 但迁移成本太高”，现在是“AI 帮我把成本砍了一半，那我就干了”。

反面声音：Rust 不是银弹

作为一个旁观者，有必要把硬币的另一面也翻出来看看。

学习曲线是真的陡。 Rust 的所有权系统、生命周期、借用检查器，对习惯了 Python、JavaScript 的开发者来说是完全不同的思维模式。有开发者戏称“和 Rust 编译器搏斗”是日常修行。

生态系统还是小。 Rust 的第三方库（crates）数量和 npm、PyPI 比差了几个数量级。虽然核心领域（网络、数据库、CLI）已经很成熟，但 niche 领域的库质量和文档还有差距。

编译速度慢。 Rust 的编译时间随着项目规模增长会变得很可观。大型项目的增量编译也要几十秒，对比 Go 的几秒出结果，开发体验有差距。

招聘难。 真正有 Rust 生产经验的工程师仍然稀缺。很多公司想用 Rust 但不敢用——因为怕招不到人。

过度重写的风险。 不是所有项目都需要 Rust 级别的性能。一个内部管理后台用 Python 跑得好好的，非要重写成 Rust，只会增加维护成本。社区里有人把这种现象叫“Rewrite It In Rust”综合症——一种看到什么项目都想用 Rust 重写的冲动。

4 月 1 日，FFmpeg 官方发了条推文：“FFmpeg is moving to Rust 🦀”，底下回复说自己“整个灵魂都建立在 C 和 Assembly 上”。这是愚人节玩笑，但评论区炸了——因为这恰好戳中了 Rust 社区的敏感神经。不是所有项目都适合、也不应该用 Rust 重写。

有人质疑微软的“2030 年消除 C/C++”计划太激进。一位开发者用讽刺的口吻写道：“1 个工程师，1 个月，100 万行代码。算下来每秒要写 1.4 行，包括睡觉时间。用 AI，一个会幻觉分号的 AI。”

它可能只是一个时代的选择，而不是终极答案。 十年前 Go 被称为“未来的系统语言”，现在它被 Rust 挑战。谁知道十年后会不会有另一个“Rust 的 Rust”出现？技术选型永远在进化，没有终点站。

旁观者说：冷静看这波浪潮

回到最初的问题：为什么 AI 时代这么多人拥抱 Rust？

答案不是单一的。它是多个因素在同一个时间点的叠加：

1. Python 生态的“性能天花板”在 AI 时代被暴露无遗——训练用 GPU 就算了，但部署、推理、工具链的慢，让人忍无可忍
2. 内存安全从“好习惯”变成了“合规要求”——政府和企业不再容忍 70% 的漏洞来自同一类 bug
3. AI 编程工具让“重写”的成本断崖式下降——以前想想就放弃的事，现在可以动手了
4. 云时代的成本焦虑——同样的功能用更少的内存和 CPU，直接省钱
5. 操作系统内核的示范效应——当 Linux、Windows、Android 都在用 Rust，普通开发者会有“该跟了”的紧迫感

这是一个真实的技术趋势，但也有过热的成分。不是每个项目都值得用 Rust 重写，不是每个团队都适合上 Rust。

如果你是技术决策者，我的建议是：关注那些高频调用、性能敏感、长期运行的模块——这些是 Rust 真正能发挥价值的地方。至于内部的 CRUD 接口和脚本，Python 和 Node.js 继续用着挺好。

如果你是普通开发者，了解 Rust 是好事，但不必焦虑。语言的更替是慢过程，Python 在可预见的未来依然是 AI 和数据科学的主流。

真正值得关注的不只是 Rust 本身，而是这个趋势背后折射出的行业共识：我们不再愿意接受“快但危险”（C/C++）或“安全但慢”（Python/Java）的二选一。开发者想要两者兼得。

Rust 恰好站在了这个交叉点上。关于这场编程语言变迁的更多讨论，也欢迎在 云栈社区 的开发者广场与其他同行交流。