从一个快了 4 倍的工具说起：非程序员眼中的 Rust

上一篇文章里我写了用 Actionbook 扫描 95 个推特账号的经历。整个过程中有一个数字一直让我觉得奇怪——

同样是抓一个账号的最新推文，Actionbook 只要 2 秒，Playwright 要 8 秒。

快了 4 倍。

当时我没多想，工具好用就继续用。但后来我在网上搜 Actionbook 相关的讨论，发现不少开发者对这个工具的作者评价很高，说是"大佬出品"。我就想：大佬选择用这个东西写，一定有他的道理。

于是翻了一下 Actionbook 的 GitHub 页面，看到一行字：Written in Rust。

Rust？我之前只是偶尔听到这个名字，从来没了解过。但既然一个让我明显感受到速度差异的工具是用它写的，那就值得花点时间搞清楚它到底是什么。

Rust 是什么

Rust 是一门编程语言，2015 年发布 1.0 版本，最初是 Mozilla（做 Firefox 的那家公司）搞出来的。到 2026 年 1 月，最新版本是 1.93.0。

官方把它叫"系统级编程语言"。说人话就是：它是用来写那些对性能要求特别高的底层软件的——操作系统、浏览器引擎、数据库这种东西。

以前这块地盘归 C 和 C++。Rust 做的事情是：跑得跟 C/C++ 差不多快，但程序不容易崩。

谁在用 Rust

如果你用过下面这些工具，其实你已经在间接用 Rust 了：

• ripgrep — 代码搜索工具，比传统的 grep 快几十倍。VS Code 的全局搜索底层就是它
• SWC — JavaScript/TypeScript 编译器，Next.js 默认用它替代了 Babel
• Turbopack — Next.js 的新打包工具，Vercel 出品
• Deno — Node.js 的替代品，Node.js 的发明者 Ryan Dahl 自己用 Rust 重写的
• agent-browser — Vercel Labs 的浏览器自动化工具，Actionbook 的底层引擎
• Cloudflare Workers — 全球最大的 CDN 之一，底层运行时是 Rust

你会发现一个趋势：很多原本用 JavaScript、Python、C++ 写的工具，都在被 Rust 重写。重写之后用户的反馈通常就一个字——快。

为什么快：三个核心原因

我不是程序员，但尝试用类比把这三个原因说清楚。

1. 提前翻译好 vs 现场口译

Python 和 JavaScript 是"解释型语言"。每次运行的时候，都要有一个"翻译官"把代码实时翻译成机器能听懂的指令。

Rust 是"编译型语言"。写完代码后，先花时间一次性翻译成机器码，生成一个可执行文件。之后每次运行都是直接执行，不用再翻译。

打个比方：解释型语言像是开会带同声传译，每句话都要现场翻一遍。编译型语言像是提前把整本会议材料翻好，开会时直接读译稿。哪个快一目了然。

2. 自己收拾桌子 vs 等保洁来收

Java、Go、JavaScript、Python 都有一个"垃圾回收器"（GC）。程序运行时会不断产生临时数据，GC 负责定期把不用的数据清理掉，释放内存。

问题是：GC 清理的时候，程序得停下来等一会儿。每次虽然只停几毫秒，但积少成多就是延迟。

Rust 没有 GC。它用一套叫"所有权系统"的规则，在编译阶段就把内存问题全解决了。编译器会检查每一块内存什么时候该分配、什么时候该释放，有问题直接编译不过，不让你跑。

打个比方：有 GC 的语言像是雇了保洁阿姨，隔一会儿来收拾一次桌子，你得停下手里的活让她干。Rust 像是从一开始就把工位设计好了——每样东西都有固定位置，用完自动归位，根本不需要保洁。

3. 写法高级，跑起来照样快

这个稍微偏技术一点。简单说就是：Rust 允许你用优雅的高级写法，但编译出来的程序跟手写底层代码一样快。

很多编程语言在"写起来方便"和"跑起来快"之间必须二选一。Rust 的设计目标是两个都要。

为什么开发者这么喜欢 Rust

Stack Overflow 每年做一次全球开发者调查。在"最受喜爱编程语言"的榜单上，Rust 已经连续好几年排名第一。2024 年的调查中，83% 用过 Rust 的开发者想继续用。2025 年这个比例是 72%，依然稳坐榜首。

开发者喜欢 Rust 的理由很直接：又快又安全。

C/C++ 很快，但写 C/C++ 特别容易犯内存错误——空指针、缓冲区溢出之类的。这些错误是安全漏洞的根源，历史上大量安全事故都是这么来的。

Rust 的编译器会在你运行程序之前就把潜在的内存问题拦住。C 级别的性能，但不用担心因为一个小疏忽把服务器搞崩。

既然这么好，为什么不全用 Rust？

了解完这些之后，我的第一个反应是：既然 Rust 又快又安全，为什么程序员不一开始就用 Rust 写所有东西？

查了一圈之后发现，原因很现实——Rust 太难学了。

Rust 的所有权系统虽然让程序又快又安全，但代价是程序员必须在写代码的时候就想清楚每一块内存的生命周期。别的语言不用操心这些，GC 帮你兜底。Rust 不行，编译器会反复"骂"你，直到你把内存管理写对为止。很多开发者说，学 Rust 的前几个月主要在跟编译器吵架。

除了学习曲线，还有一个更实际的问题：不是所有场景都需要那么快。写一个内部用的数据处理脚本，Python 半小时搞定，Rust 可能要写半天。一个网页的后端 API，响应时间从 50ms 降到 5ms，用户根本感受不到区别。性能过剩和开发效率之间是有取舍的。

所以现实是：Rust 适合写那些对性能和可靠性要求极高的基础设施和工具——CLI、编译器、运行时、数据库引擎。而上层的业务逻辑、快速原型、数据分析这些，Python 和 JavaScript 的开发速度优势更大。

这也解释了为什么 Rust 的使用模式是"重写"而不是"从头写"——先用 Python/JS 快速验证想法，等确认了性能是瓶颈，再把关键部分用 Rust 重写。

那让 AI 用 Rust 写不就行了？

我紧接着想到的第二个问题是：我们现在都在 vibe coding、用 AI 写代码，既然 Rust 难学但性能好，干脆让 AI 来写 Rust 不就解决了？ 人类不用受苦，机器帮你处理 Rust 的复杂度。

查了一下，发现这个想法不仅合理，而且已经在发生了。

现在的 AI 模型写 Rust 已经写得相当好。Claude Opus 4.5 在 SWE-bench 多语言测试中，8 种编程语言里有 7 种排名第一，其中就包括 Rust。更夸张的是，有个开发者用 Claude 两周就写出了 7 万行 Rust 编译器代码。Shuttle（一个 Rust 云平台）做过测试，Claude 能从一句话的需求描述直接生成一个完整的 Rust 全栈 Web 应用——带数据库、前端、部署配置。

而且有一点很反直觉：Rust 的严格编译器反而是 AI 写代码的优势。Python 写错了可能运行时才报错，你得自己排查。Rust 写错了，编译器会直接告诉你哪一行有什么问题。这种精确的错误反馈对 AI 特别友好——AI 可以根据编译器的提示精准修复，形成"写 → 编译 → 修复"的高效循环。

所以 Rust"难学"这个门槛，对人类是问题，对 AI 反而不是。Rust + AI 可能是一个比想象中更好的组合：AI 负责处理 Rust 的复杂度，人类享受 Rust 的性能。“又快又难写"正在变成"又快又好写”。

实际操作：我该让 AI 用 Rust 写我的项目吗？

想到这一步之后，我产生了一个更具体的问题：我现在用 Claude Code 做 vibe coding，能不能直接让它全部用 Rust 写？

查了一圈实际案例，发现答案比想象中乐观。有个开发者用 Claude Code 写了一个 Rust 扩展来优化他的 Python 数据管道，Claude 几乎一次就生成了能用的代码，性能直接提升了 10-50 倍。关键是——这哥们自己不会写 Rust。

HackerNoon 上有篇专门讲用 Claude Code 写 Rust 的文章，核心结论是：Rust 的严格编译器反而让 AI 写代码更靠谱。“if it compiles, it probably works”（能编译就大概率能跑）不只是 Rust 社区的口号，正在成为 AI 辅助开发的实际体验。

但真正的摩擦不在 AI 写代码这一步，而在整个生态上。

Rust 编译时间比 Python 慢得多，每次改完代码都要等编译。Web 开发的库和框架远不如 Python 和 JavaScript 成熟。遇到问题去搜，Python 的解答是 Rust 的几十倍。部署打包也更复杂。

所以问题不是"AI 能不能用 Rust 写"，而是"你的项目现在需不需要 Rust"。

实际的最佳实践是分阶段：先用 Python 快速出 MVP 验证想法，确认了再把性能瓶颈的部分用 Rust 重写。不是 A 或 B，而是先 A 后 B。

那个开发者的做法就是这个思路的典型案例：他先用 Python 写了一个能跑的版本，然后把这个 Python 版本当作"参考答案"，让 AI 用 Rust 重写同样的逻辑。Python 版本既是原型，也是验证 Rust 版本正确性的测试用例。

作为非程序员的收获

说实话，我不会写 Rust，短期内大概也不会学。但这次从"工具好用"到"为什么好用"的追问，让我有了几个新认识：

“用 Rust 写的"正在成为一种品质信号。 就像十年前"用 Go 重写"代表团队认真对待并发性能，现在"Written in Rust"意味着团队在追求极致的速度和可靠性。当我在 Actionbook 的 README 上看到这行字时，我对它的性能就有了一个预期——实测验证了这个预期。

不需要会写 Rust 也能从中受益。 以后遇到功能相同的两个工具，一个 Python 写的一个 Rust 写的——选 Rust 那个，大概率更快更省资源。

好工具背后的技术选择是有逻辑的。 Actionbook 快不是因为什么黑科技，是因为 Rust 从设计之初就在追求"快"和"安全"的统一。理解了这个逻辑，选工具时就多了一个判断维度。

就像买车一样——不需要懂发动机原理，但知道涡轮增压比自吸在同排量下更有劲，选车时就多了一个参考。

Rust 大概就是编程语言世界里的涡轮增压。