Blazingly Fast or Blazingly Hyped? A Reality Check on Rewriting in Rust

用 Rust 重写：性能、失败与 2026 年现实检验

RustRover

关注真正重要的事情

关注：

• 关注：

• X X

下载

RustRover

火热的性能还是过度炒作？用 Rust 重写的现实检验

Irina Mihajlovic

本文由 cot.rs 的联合维护者 Mateusz Maćkowski 和 Marek Grzelak 撰写，并作为 Rustikon 2026 的演讲者。你可以在这里观看完整演讲。

RIIR。如果你在开源社区中花费过时间，你一定见过这种情况。有人在 C 或 C++ 项目上提出一个议题，建议用 Rust 重写以实现内存安全和性能提升。有时这是一个认真的提议，有时则只是一个梗。到了 2026 年，这确实两者兼而有之。

我们想弄清楚到底哪种情况更常见。不是通过理论分析，而是通过观察人们实际进行重写后的结果。包括取得的成果、性能数据、三年后被放弃的项目，以及新写入的 Rust 代码中出现的 CVE 漏洞。我们在这个生态系统中已经待了足够长的时间，见证过所有这些情况。这篇博客文章基于我们在 Rustikon 2026 上的演讲，是我们对这一现象进行诚实审视的尝试。

TL;DR

• RIIR 可以带来真实的性能和安全性提升，但并非自动实现。有些项目因为使用了 Rust 而更快，有些则仅仅是因为从头开始重写。

• 重写会引入新漏洞。即使是有充足资金和经验丰富的工程师团队，也会犯错。

• 并非所有重写都能成功。Prisma、Loglog Games 以及 curl/hyper 的集成都因不同原因遭遇了障碍。

• 二进制文件体积、平台支持和与其他语言的互操作性是真正的实际挑战。

• 几乎所有情况下，最佳方法都是逐步扩展，而不是一次性全部重写。

• Rust 在 Linux 内核和 Windows 中的应用，可以说是 RIIR 运动迄今为止最大的验证。

什么是 RIIR？为何会兴起？

RIIR 的全称是 "Rewrite It In Rust"（用 Rust 重写）。这个短语最初出现在 C 和 C++ 项目的议题跟踪器中，作为建议迁移到内存安全且性能优异的替代方案的一种方式。根据 Google Trends 的数据，"rewrite rust" 这个术语在 2022 年左右显著上升，我们认为这与 Rust 2021 版本的发布大致吻合，尽管当时发生了许多事情，我们并不声称对此有确切的了解。

人们在考虑重写时选择 Rust 的原因可以归结为三点：

• 内存安全

• 性能

• 无畏的并发

在内存安全方面，Android 团队的数据难以反驳。自从 Android 开始将新开发转向内存安全语言后，代码库中 Rust 代码的开发速度稳步上升。数据显示出明显的线性相关性：随着内存不安全代码的开发速度下降，内存安全漏洞的数量也随之减少。

就性能而言，2017 年一篇比较不同编程语言在能源效率、执行时间和内存使用方面的论文显示，Rust 在能源效率和执行速度上都名列前茅。该方法并不完美，语言之间的直接比较也存在困难，但结果仍指向一个更广泛的趋势：Rust 在速度和效率方面都具有竞争力。内存使用量高于绝对最佳表现者，但仍在比较的上半部分。

然后还有 Stack Overflow 开发者调查。多年来，Rust 一直是开发者最推崇的语言。许多 RIIR 项目的存在可能仅仅是因为开发者想用 Rust 编写代码。这一点值得坦率地承认。

三种重写类型

并非所有重写都相同，明确说明你讨论的类别很有帮助。这里我们有三类。

即插即用替代方案旨在在功能上与原始实现完全一致。你只需替换二进制文件，其他一切保持不变。uutils coreutils、sudo-rs、作为容器运行时替代方案的 youki，以及作为 Tor 重实现的 Arti 都属于此类。生态系统中存在数千个此类项目，从像 PNG crate 替换 libpng 这样的小型文件格式库，到拥有大量企业与社区资金支持的大型基础设施项目。

替代方案解决相同的问题但做出不同选择。例如 ripgrep 代替 grep、delta 代替 diff、bat 代替 cat、Typst 代替 LaTeX、Polars 代替 pandas。这些方案并不追求完全一致的替代，通常更快、更符合人体工程学，或基于不同的设计理念。Typst 是可读性优势的典型案例：

LaTeX 和 Typst 可以生成相同的输出，但源代码讲述的是截然不同的故事。在原始性能方面，Marek 对 37 GB 的 cargo 目标目录搜索单词 "cot" 进行了测试。grep 用了 52 秒完成，ripgrep 仅用了 6 秒。这不是微不足道的差异。

自重写是指现有项目决定用 Rust 重写自身部分或全部代码，而无需替换外部二进制文件。Firefox、Linux 内核、Windows、Cloudflare 的基础设施以及 Fish shell 都属于此类。这些都不是小规模的尝试。如今世界上部署最广泛的部分软件已包含 Rust，而它们正是通过此类重写实现的。

Rust 重写性能：是否真的能带来提升？

有时确实如此，有时却出于错误的原因。以 uutils 为例，其 sort 工具的运行速度几乎是 GNU sort 的四倍。原因在于并行归并排序，而 Rust 的并发模型使这种算法的正确实现变得显著更容易。但其他工具的速度提升可能仅仅是因为它们是经过 30 年经验沉淀后的新实现。原始项目无法像现在这样自由实验，因为生产用户依赖着它们。

PNG crate 更能体现 Rust 特有的性能优势。Rust 实现的速度几乎是 libpng 的两倍。其中一部分优势来自自动向量化：Rust 编译器能从普通 for 循环自动生成 SIMD 指令，而大多数 C 实现需要手动编写 SIMD 代码。另一部分优势来自流式 DEFLATE 解压缩，这种技术能一次性将更多数据装入 CPU 缓存。这两点都是 Rust 真实的性能优势。

Rust 二进制文件大小：问题及解决方案

Rust 二进制文件以体积庞大著称，背后有真实原因：panic 处理代码、Debug trait 实现、每个二进制文件中编译的完整标准库、泛型带来的单态化（monomorphization），以及所有依赖项的静态链接。

uutils 通过多调用二进制格式解决了这个问题，这种方案与 BusyBox 采用的方式相同。所有工具都被编译到一个二进制文件中，并通过符号链接进行调用。结果：原本 73 MB 的独立二进制文件缩减为 13.8 MB 的多调用二进制文件，实际上甚至优于 GNU coreutils 标准安装的 18.4 MB。经过 UPX 压缩后，体积进一步缩小到 5 MB。

这个问题是可以解决的，但需要付出大量努力。

用 Rust 重写：可能出错的地方和原因

这个话题往往被讨论得不够充分。每次重写都会引入新 bug。你从零开始编写代码，这意味着不可避免地会引入原始项目中未发现的新 bug 或回归问题。这并不是 Rust 特有的问题，而是软件重写普遍存在的挑战。但我们需要清醒地认识到这一点。

Cloudflare 在请求评分组件中引入了一个 unwrap 操作。uutils 的日期格式存在轻微错误，导致无人值守升级失败。sudo-rs 在超时后将部分输入的密码回显到终端。Linux 内核中首个 Rust 代码的 CVE 漏洞来自 Android binder 驱动中 unsafe 块的竞态条件。TARmageddon 是 async-tar 因错误解析 .tar 格式而引发的远程代码执行漏洞。

如果资金雄厚且团队经验丰富的企业仍会犯这些错误，我们也会如此。这并不是不进行重写的理由，但确实需要认真对待测试工作。有时，Rust 甚至不是最佳选择。微软选择用 Go 重写 TypeScript 编译器，主要是因为 Go 的编程模型更接近 TypeScript，这在代码库同时包含两种语言的过渡期尤为重要。NTPsec 项目选择 Go 是因为当时 Go 在网络原语和生态系统碎片化程度方面表现更优。这些决策是合理的，并非想象力的失败。

一些选择 Rust 的重写项目也未能成功。Prisma 因技能缺口、部署复杂性和运行时问题，重新迁回 TypeScript。Loglog Games 在三年游戏开发后放弃了 Rust，他们发现 Rust 虽适合重构，但迭代速度较慢，且 Rust 游戏开发社区更关注引擎技术细节而非交付成品游戏。curl/hyper 集成项目完成了 95% 的工作后因最后 5% 的难度和社区动量不足而被放弃。有趣的是，这次合作仍然为两个项目带来了好处：尝试整合的过程促使两个代码库都进行了强制性清理。

许可证选择是一项真实决策

在 RIIR 讨论中，很少有人提及一个关键点：如果你正在创建一个重新实现现有项目的全新项目，许可证选择会产生实际影响。

更严格的许可证（如 GPL）可能会排除无法在专有项目中引入 copyleft 依赖的用户。更宽松的许可证可能招致开源社区的批评，因为一些人担心公司会使用代码而不回馈社区。没有放之四海而皆准的正确答案，这完全取决于你的项目目标和社区定位。但这是一个值得有意识做出的决策，而不是默认选择。

2026 年 RIIR 运动仍在继续吗？

The RIIR meme has faded somewhat. But the actual movement hasn’t. Rust in the Linux kernel is no longer experimental, and the maintainers declared the experiment a success at the 2025 Maintainers Summit. Rust is running in the Windows kernel. Cloudflare, Firefox, and countless infrastructure projects have committed significant Rust code to production.

The scale is real. Between Linux and Windows alone, Rust is running on billions of devices. That’s arguably the biggest validation the “rewrite it in Rust” idea has ever received.

How to actually do it well

If you’re considering a rewrite, a few things we’d recommend thinking through first. Make sure it actually makes sense for your use case. Ask whether your codebase is in a memory-unsafe language, whether it’s critical software, whether you have real performance and reliability requirements, and whether you have significant parallel or concurrent code that’s hard to reason about. The more of those boxes you check, the stronger the case.

Make sure your team is ready. Either they already know Rust, or they’re genuinely willing to learn and contribute to it. Google’s data suggests that around two-thirds of developers feel confident contributing to a Rust codebase within two months. But that’s not a guarantee, and the last 5% of a rewrite is almost always harder than you expect. Small rewrites take months. Medium ones take one to two years, and large rewrites take two to five. It almost always takes longer than you estimated.

Prefer expanding incrementally over rewriting completely. Adding new components in Rust while keeping the old codebase running is almost always less risky than a full replacement. You get the benefits without betting the whole project on it.

When you do rewrite, build a serious test suite. The best example of this in practice is uutils, which runs against the official GNU coreutils test suite to track parity. As of early 2026, they’re at 92.2% pass rate and climbing.

So is it worth it?

If your project is written in a memory-unsafe language, handles critical functionality, has real performance requirements, and involves substantial concurrent code, yes. A rewrite is strongly justified, and the evidence supports it.

Outside of those conditions, it’s still potentially worth it, but the analysis needs to be more careful. The enthusiasm is understandable as Rust is genuinely good. But it was designed as a systems programming language, and that’s where it does its best work. Treating RIIR as a default answer to every performance or safety concern is how you end up with a two-year rewrite project that ships six months late and introduces bugs you already fixed.

Frequently Asked Questions

What does RIIR mean? RIIR stands for Rewrite It In Rust. It started as a suggestion in open-source issue trackers to migrate C and C++ projects to Rust for memory safety and performance, and became a broader cultural meme in the Rust community.

Is rewriting software in Rust worth it? It depends on your situation. If your codebase is in a memory-unsafe language, handles critical functionality, and has real performance or concurrency requirements, the case for a Rust rewrite is strong. In other situations, the benefits are less clear, and the costs, but the learning curve, rewrite time, and new bugs deserve serious consideration.

用 Rust 重写存在哪些风险？每次重写都可能引入新 bug，包括原始项目已修复的 bug。Rust 重写还需要开发者学习新语言，耗时可能远超预期，并面临平台支持、二进制体积和与其他语言互操作性等挑战。

迁移到 Rust 的最佳方式是什么？采用渐进式扩展而非全面重写。在保留现有代码运行的同时，用 Rust 添加新组件。进行重写时，应投入精力构建完善的测试套件，确保新实现的行为与原始代码完全一致。

Rust 在 Linux 内核中取得成功了吗？是的。在 2025 年 Linux 内核维护者峰会上，与会者一致认为 Rust 实验取得了成功。目前 Rust 已成为内核的核心组成部分，不再被视为实验性技术。

rust 重写

RIIR

• 分享

• Facebook

• Twitter

• Linkedin