本文永久链接 – https://tonybai.com/2026/08/15/rust-rewrite-blazingly-fast-or-hyped-rustikon-2026
大家好，我是Tony Bai。
【导读】
“Rewrite It In Rust”曾是开源世界里最响亮的口号之一。从coreutils到Linux内核，从sudo到Windows底层组件，一场声势浩大的“重写运动”席卷了整个开发者社区。但当热度褪去，这些重写项目真的如宣传中那样“blazingly fast”吗？在Rustikon 2026大会上，来自RTB House的两位工程师Mateusz Maćkowski和Marek Grzelak，用一组组实测数据和翻车案例，给这场持续了三年的迷因，交出了一份不站队、不夸大的诚实答卷。
如果你在GitHub上蹲过issue区，大概率见过这样的场景：项目卡在一个性能问题上迟迟无解，评论区总会飘来一句——“为什么不用Rust重写？”
这句调侃甚至有了自己的名字，叫RIIR（Rewrite It In Rust）。根据Google Trends的数据，这个梗大约从2022年前后开始起势，差不多也是Rust 2021 edition发布后的那段时间，虽然具体是什么触发了它，两位演讲者也坦言“说不清楚，这几年发生的事情太多了”。
三年过去，这场运动到底走到哪一步了？是像宣传的那样“blazingly fast”，还是只是“blazingly hyped”（被过度炒作）？Rustikon 2026大会上，这场演讲试图用实测数据而不是情绪，把这件事说清楚。
【文章要点】
- RIIR（Write It In Rust）热潮从2022年前后兴起，如今仍在继续，Linux内核与Windows内核引入Rust被认为是这场运动最大的两个成功案例
- 重写项目可分为三类：直接替代二进制的“drop-in替代”、换了思路的“平行替代品”、项目内部的“自我重写”
- 性能提升有真凭实据：uutils的sort并行提速近4倍，PNG库靠SIMD自动向量化和流式解压快了近2倍
- 但“重写就一定快”是幻觉：bat在非交互模式下比cat慢60倍，lsd因为系统调用暴增而变慢
- Rust著名的“大体积二进制”问题，可以用multi-call binary技巧把uutils从73MB压到14MB
- 重写不等于零bug：Cloudflare、uutils、sudo-rs、Linux binder驱动、async-tar都栽过跟头
- 学习曲线和工期都容易被低估，实际耗时往往是预估的2到3倍
- 也有反例：微软TypeScript编译器选了Go而不是Rust，Prisma、LogLog工作室、Hyper与Curl的集成都最终放弃了Rust
大家为什么想用Rust重写
演讲开门见山，先给出了三个最常被提到的理由。
第一是内存安全。 谷歌Android官方博客披露，由于Android长期执行“新的裸机代码不得使用内存不安全语言编写”的政策，Rust代码在代码库中的占比持续上升。更关键的是，数据显示内存不安全语言的代码行数与内存安全漏洞数量之间存在明显的线性相关——不安全代码越少，漏洞也越少。
第二是性能。 演讲引用了2017年一篇对比多种编程语言能效、性能与内存占用的论文。结果显示，Rust在能效和性能两项指标上几乎是所有被测语言中表现最好的，内存占用虽算不上第一梯队，但也稳居中上游。当然，具体表现因项目而异，但“至少不差”是一个相对稳的预期。
第三是“无畏并发”（fearless concurrency）。 所有权模型、借用检查器、Send/Sync trait，这些机制不仅让并发代码更容易写对，客观上也让代码整体更不容易出bug。
而最后一个理由，两位演讲者说得很实在：Stack Overflow开发者调查里，Rust已经连续多年蝉联“最受开发者喜爱的语言”。很多重写项目的起点，可能就是一句朴素的“为什么不呢”。
重写的三种类型
为了让讨论更系统，演讲把形形色色的Rust重写项目归纳成三类（虽然演讲者也承认这个划分并不绝对，有些项目会横跨多类）：
- Drop-in替代：目标是完全兼容原有二进制，装上去就能直接用。典型代表是uutils（GNU coreutils的Rust重写）、Trifecta Tech Foundation旗下的sudo-rs、tty-rs，以及PNG、tar等文件格式解析库，还有替代runC的容器运行时Youki。
- 平行替代品：解决同样的问题，但交互方式和思路有所不同。终端工具里的ripgrep、bat、jj、just都是这一类；更“重”一点的还有替代LaTeX的Typst、替代pandas的Polars。（笔者注：还有前段时间引发社区热议的Bun重写）
- 自我重写：项目内部主动决定用Rust重写全部或部分代码，不再维护旧版本。Codex CLI（原TypeScript）、Fish（原C++）、Cloudflare的大量基础设施，都属于这一类。
而这场运动里公认最重量级的三个案例，是Firefox、Linux和Windows——毕竟Rust最初就是为Firefox而生的，如今Rust已经进入Windows内核，Linux维护者也已经确认“Rust for Linux”实验取得成功，Rust会留下来。演讲者称这两件事是这场重写运动“目前最大的两项成就”，让Rust跑在了全球数十亿设备上。
性能到底快在哪里：三个实测案例
光讲理念不够，演讲用几个真实项目的数据说明了Rust重写为什么真的会更快。
uutils的sort： 比原版GNU coreutils快了近4倍，主要靠的是并行处理——而在Rust里写并行代码，明显比在C里更容易、更安全。但演讲也提醒，这种提速有一部分要归功于“重写”本身：写一个没有历史包袱、没人依赖的新项目，天然就有更大的优化空间，这未必是Rust独有的红利。
PNG解码库： 比对应的C库快了近两倍。原因藏在PNG的编码原理里——PNG本质是先做差分预测再用deflate算法压缩。Rust版本快在两处：一是PNG filter阶段需要对大量数据做SIMD（单指令多数据）运算，多数库靠手写SIMD指令，而Rust编译器擅长自动向量化，写一个普通的for循环，只要写法得当，编译器就能自动生成SIMD指令；二是deflate阶段，其他库通常一次性解压整个文件，Rust版本因为语言特性更容易做流式解压，数据能更多地留在CPU缓存里，效率自然更高。
但演讲随即抛出一个问题：重写就一定更快吗？答案是否定的。bat在非交互模式（也就是纯管道输出、不涉及终端渲染）下，实测比cat慢了整整60倍；lsd因为要展示比原版ls更多的信息，触发了大量额外的系统调用，同样出现了性能倒退。好消息是，这些问题后来都被较快地修复了——这也从侧面说明，Rust社区确实在乎性能这件事，光靠语言本身写出快代码是不够的，还得有人真的去做这件事。
绕不开的槽点：二进制体积
Rust另一个广为人知的“槽点”是二进制体积偏大，原因包括panic处理携带的代码位置信息、Debug trait的默认实现、标准库整体静态链接进可执行文件，以及泛型带来的单态化（同一份代码可能被编译出多份副本）。
针对这个问题，uutils用了一个老技巧——multi-call binary（多合一可执行文件），这个思路busybox早年就用过：把一堆共享代码的小工具打包进一个大的库式二进制文件，再给每个工具名建符号链接，程序运行时根据被调用的文件名决定要执行哪个具体功能。
效果很直接：uutils的体积从73MB压到了14MB，反超了原版GNU coreutils，虽然仍然比busybox大。
重写要付出的隐藏代价
如果说前面几节还算是“重写的正面案例”，这一部分演讲开始转向更冷静的一面。
新bug是免不了的。
从零重写一遍代码，几乎必然会引入新bug，或者重新踩到原项目早就修过的坑。
演讲列了几个真实例子：Cloudflare在其机器学习请求评分组件中引入了一个unwrap导致的问题；uutils的日期格式化工具曾出现细微偏差，破坏了向后兼容；sudo-rs曾出现过密码输入超时后，已输入的部分密码会被回显到终端；Linux Android binder驱动里出现过Rust代码的首个CVE，起因是一个不安全代码块里的竞态条件，导致内存损坏和崩溃；还有Termageddon——一个由async-tar格式解析错误引发的远程代码执行漏洞。
演讲者的结论很直白：这些都是有资金、有资源、认真对待的大项目，尚且会犯这些错误，普通团队同样会犯，写Rust不等于自动免疫bug。
学习曲线是真实成本。
借用检查器、生命周期，更不用提async——这些都是公认的Rust学习门槛。
谷歌的一项调查发现，大约2/3的开发者在接触Rust代码库约两个月后会感到“有信心贡献代码”，但这只是平均值，有人更快，也有人需要长得多的时间。
重写本身极其耗时，而且总被低估。
演讲援引了一份统计：小型重写通常需要几个月，中型项目要1到2年，大型项目可能耗时2到5年。
更麻烦的是，几乎所有团队对重写工期的预估最终都会被现实打脸——通常要多花2到3倍的时间，而且最后的5%到10%往往是最难啃的部分，需要把所有细节都做到和原版完全一致，这最后一段路常常决定了整个重写“值不值”。
那些放弃了Rust的项目
除了工期和bug，Rust也不是所有场景下的最优解，演讲举了几个“知难而退”的真实案例：
- 微软TypeScript编译器：最终选择了Go而不是Rust，原因是这个项目并不需要那么极致的安全性和性能，Go已经够用。
- Prisma ORM：曾尝试用Rust重写核心，最终决定回归TypeScript，原因包括团队技能栈匹配度、部署和运行时问题，以及TypeScript版本编译出的二进制反而更小。
- LogLog（独立游戏工作室）：使用Rust三年后放弃。他们承认Rust在重构方面确实好用，但迭代速度太慢——游戏开发中大量对象相互引用，这恰恰是借用检查器最不擅长处理的场景，加上编译时间偏长。更值得玩味的一句评价是：Rust游戏开发社区似乎更热衷于讨论引擎本身的技术细节，而不是把游戏真正做出来发布。
- Hyper与Curl：libcurl曾尝试引入Hyper作为其网络请求后端，做到了95%的进度，但和前面提到的规律一样，最后5%最难，加上社区兴趣不足，这个集成最终被放弃。不过这次尝试并非全无收获——两个项目在互相适配的过程中都做了重构，最终代码质量都有所提升。
还有一道容易被忽略的题：许可证
重写往往也意味着一次重新选择许可证的机会。如果沿用原许可证，一切照旧；如果换成限制更多的许可证（比如GPL），可能会让原来的部分用户望而却步——比如不愿意在专有产品中引入GPL依赖的公司；反过来如果换成更宽松的许可证，又可能招来“大公司白嫖代码却不回馈社区”的批评。
演讲者的态度很坦率：这个问题没有标准答案，取决于具体情况，但确实是重写前值得认真考虑的一环。
小结：到底该不该重写
回到最初的问题——RIIR这场运动，如今还在继续吗？演讲的答案是：迷因本身或许已经褪去了一些热度，但重写这件事本身，热情丝毫未减。
而这场运动目前最大的成功案例，依然是Linux内核和Windows内核对Rust的接纳，加上覆盖服务器与用户端的海量工具项目，规模摆在那里。
关于是否值得重写，演讲给出了一个相对朴素的判断标准：如果你的项目当前使用内存不安全语言编写，属于某种关键性软件，对性能和可靠性有明确要求，同时有大量并行代码，那这值得认真考虑；否则，就需要自己权衡了。
如果决定动手，演讲也留下了几条建议：
- 先确认这件事真的值得做：团队和社区是否懂Rust或愿意学，Rust编译器是否支持你需要的所有平台，二进制体积是否会成为问题——这些都要提前想清楚。
- 优先考虑“扩展”而不是“整体重写”：用新语言给项目添加新功能，往往比把旧代码全部推倒重来更简单，也不用重新面对那些老bug。
- 准备一套扎实的测试套件：确保重写后的行为和原版严格一致。uutils就是一个很好的范例——他们直接复用了GNU coreutils自己的测试套件来验证兼容性，目前已经做到了接近100%的行为对齐。
Rust重写运动走到今天，早已不是一句“blazingly fast”就能概括的故事。它有真实的性能红利，也有真实的翻车现场；有Linux内核这样的标杆级成功，也有Prisma、LogLog这样体面退场的案例。或许这才是这场持续多年的迷因，最值得被记住的地方：它从来不是非黑即白的选择题，而是一次次需要认真权衡的工程决策。
本文内容整理自Rustikon 2026大会演讲《Blazingly Fast or Blazingly Hyped?》，演讲者：Mateusz Maćkowski、Marek Grzelak（RTB House）。演讲视频：https://www.youtube.com/watch?v=eg_FXIAMA5g
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
