2026 年用 Rust 重写：现实检验
Rewriting in Rust
作为 cot.rs 的维护者，我们在 Rustikon 2026 上分享了对“重写为 Rust”（RIIR）运动的现实观察。虽然 Rust 在内存安全和性能上优势明显，但重写并非万能药。从 uutils 到 Linux 内核，成功案例背后是巨大的投入；而 Prisma 和 Loglog Games 的撤退则揭示了技能缺口和迭代速度的挑战。重写会引入新漏洞，二进制体积也是难题。我们建议优先考虑增量扩展而非全盘重写，并建立严格的测试体系。Rust 在 Linux 和 Windows 内核中的落地证明了其价值，但盲目跟风只会带来延期和 Bug。
将 RIIR 视为解决所有性能或安全问题的默认答案，最终只会得到一个延期半年发布且引入已知漏洞的重写项目。
- collinfunk
注：我是 GNU coreutils 的联合维护者。这是否让我的观点显得相关、有偏见，或者两者兼有，由你自行判断。:)
我真的很希望他们能在这里说明基准测试的方法论，或者至少提醒读者不要仅凭展示的基准测试结果就贸然下结论。
GNU 'sort' 的性能会受到所用 locale、输入数据以及 --buffer-size 和 --parallel 选项参数的显著影响。GNU 'sort' 在默认使用的线程数上相当保守，据我的经验，比 uutils 保守得多。这是因为给 'sort' 增加线程数可能会让它变快（也可能不会），但也存在耗尽内存的风险。这正是 uutils 的问题所在：它在判断何时使用外部排序时表现不佳：
$ export LC_ALL=C
$ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
$ time sort input > /dev/null
real 0m24.245s
user 0m0.896s
sys 0m19.161s
下面是使用最新 uutils 提交版本（通过 'make PROFILE=release' 编译）运行相同命令的结果：
$ time uu-sort input > /dev/null
Killed uu-sort input > /dev/null
real 2m53.560s
user 1m40.634s
sys 0m59.847s
该进程被 OOM killer 杀死了。这很可能是因为 uutils 'sort' 决定使用 18 个线程，而 GNU 'sort' 只用了 1 个。我有点沮丧的是，这些基准测试在没有方法论或引用依据的情况下就被抛了出来，因为它们往往会被人们不加质疑地采信。这些测试可能会造 […]
- BluSyn
一个相关的小插曲：
刚才正在测试最新一代 LLM 的能力，决定让它尝试用 Rust 重写一个小型开源项目。（需要说明的是：这不是某个极小的库，而是一个真正有用的网络服务）。
它在大约 2 小时内完成了从 TypeScript 到 Rust 的整个重写工作，消耗了约 60 万 tokens。第一次尝试就完美运行，无需任何后续修改。内存和 CPU 占用率现在仅为 TS 版本的极小一部分（这是显而易见的）。Rust 代码简洁易读，测试套件准确等。
我感到 pleasantly surprised（惊喜）。
显然，拥有更复杂业务逻辑的大型代码库在这里可能会遇到挣扎，但在性能至关重要的场景下，"用 Rust 重写它"（RIIR）确实有一些优势，即便抛开安全效益不谈。Rust 有助于从旧硬件中榨取更多性能；尤其是在当前内存价格高企的情况下，减少内存占用尤其有帮助。
对于运营成本至关重要的中小型服务来说，让 LLM "用 Rust 重写它" 或许值得这笔投入。
- tonyedgecombe
有那么一瞬间，我还以为 JetBrains 正在用 Rust 重写他们的工具，我们马上就能享受到性能提升了。