Claude和Codex改写35个生信软件:Rust到底强在哪?

实验室里最让人头疼的，常常是那种还能跑、却没人敢改的程序。

作者毕业了，博士后去了别的机构，服务器里留下几万行Perl、Fortran或C/C++。依赖锁在老版本里，换台机器就报错；想加一个功能，谁也说不准会不会把十年前的计算结果一起改掉。科研软件的“遗产”大多不是废品，它们仍在出结果。麻烦恰恰在这里。

2026年8月，Umeå University的Johan Henriksson上传了一篇单作者预印本。他报告了一次很激进的尝试：用Claude、Codex和静态分析工具，在11周里推进约40次迁移，其中35个生信与成像软件包到了“已测试、已benchmark、可供早期采用者使用”的状态。

这句话后面还有半句，不能省：作者预计其中仍有翻译缺陷。 论文所指的“可用”，是团队已经开始在生产环境采用，不是35个项目都拿到了独立复现和长期维护的毕业证。论文声称公开了benchmark数据，但对应GitHub仓库目前仍是404，所以整套性能结果还无法从外部复跑。

这个案例更值得追问的是：为什么这些老软件偏偏要迁到Rust？

CHAPTER 01

Rust是什么

Rust是一门编译型、静态类型的系统编程语言。你写完代码，编译器把它变成本机能直接执行的二进制程序。它不依赖垃圾回收器，也没有Java、Python那样的语言运行时。官方给出的三个关键词很直白：性能、可靠性、生产力。

“系统编程语言”听起来像是只给操作系统和驱动用的。现在这个边界已经宽得多：命令行工具、数据库、网络服务、浏览器组件、嵌入式设备、WebAssembly，以及需要处理大量数据的科研软件，都能看到Rust。

它也不是Python或R的平替。你要快速画张图、试一个统计模型、在Notebook里改两行就看结果，Python和R通常更顺手。Rust更像是在代码要长期跑、跨机器发、性能和稳定性都开始要账的时候出场。

CHAPTER 02

所有权：每块数据都得有人负责

Rust最出名，也最容易把初学者劝退的，是所有权。

可以把内存里的数据想成仓库中的箱子。每个箱子有一个负责人；负责人离开作用域，箱子就会被自动清走。如果函数只是看看箱子里的东西，可以借一个只读引用。想修改，就要拿到可变引用，而且同一时刻只能有一个。

规则不复杂，写起来却会卡手。你明明只是想把一个字符串交给两个函数，编译器却追着问：谁拥有它？谁只是借用？借多久？中途有没有人修改？

这种“烦”，是用Rust要先付的成本。C和C++允许你直接摆弄指针，很多错误要等程序跑起来才露头：对象已经释放，指针还在用；两个线程同时改一块内存；一个引用活得比原数据还久。Rust要求你在编译时先把关系说清楚。

我在本地写了一个最小FASTA统计程序。它读取两条序列，得到10个字符、6个G/C，GC比例60.0%。两个测试都通过：一个核对已知答案，另一个确认没有header的输入会被拒绝。随后我故意对同一个字符串建立两个重叠的可变借用，程序还没运行，rustc就以E0499拒绝了编译。

这正是借用检查器干的事：把一部分运行期事故，提前变成开发阶段的编译错误。

注意“一部分”。Rust不会检查你的统计模型选错了没有，也不知道GC比例的分母该不该排除N；它防不住错误算法、错误实验设计、死锁和不公平benchmark。进入unsafe或通过FFI调用C库时，裸指针和外部函数的正确性仍要由开发者负责。

CHAPTER 03

没有GC，为什么还能自动管内存

很多语言用垃圾回收器定期寻找“没人再用”的对象。开发者省心了，运行时要为扫描、暂停或额外内存付账。Rust换了条路：编译器根据所有权和生命周期，确定一个值什么时候该被销毁，再把清理代码编进程序。

所以Rust可以同时做到两件事：不用手写free，也不需要后台垃圾回收器。这让它的内存占用和延迟更容易预测，适合服务端、嵌入式和大数据处理。

不过，“无GC”不是速度保证书。算法慢，Rust照样慢；反复分配内存、拷贝大数组、把I/O写得很差，换语言也救不了。更具体地说，Rust给了你更细的资源控制，同时让safe Rust替你守住一批内存边界。

CHAPTER 04

Cargo把散落的零件装进同一个工具箱

一门语言能不能在团队里活下去，工具链往往比语法更重要。Cargo同时承担包管理和构建：下载依赖、编译项目、制作可分发包，也能把库发布到crates.io。

那篇生信迁移论文也展示了一个很实际的收益。Bascet原来靠Conda和容器粘住许多上游程序。作者把上游依赖迁成Rust库后，用Cargo统一管理，最后分发一个约200MB的二进制文件；论文称它比原容器小约80倍，按这个倍率折算，原容器约16GB。构建时间则从20分钟缩到约1–2分钟。

这组数字很亮眼，但功劳不能全记在Rust语法上。体积下降同时来自去掉容器、减少系统依赖、把多个命令行程序改成库，以及单二进制打包。换一个项目，结果可能完全不同。

Cargo的长期价值，是让“怎么拿依赖、怎么编译、怎么测试、怎么打包”有一套共同入口。对于几年后还要重建的科研软件，这比一时跑得快多少更耐用。

CHAPTER 05

并发更敢写，边界也更硬

科研计算经常要吃满多核。传统共享内存并发最难查的，是数据竞争：两个执行单元同时碰同一块数据，其中至少一个在写，却没有同步机制。它可能只在某台机器、某个负载、某次调度里出现。

Rust把所有权和类型系统延伸到了并发。许多不安全的共享方式直接无法通过编译；数据能否跨线程移动、能否被多线程共享，也通过Send和Sync等约束表达。

这不会自动写出高性能并行程序。锁粒度不对，照样能慢；锁的顺序不对，照样可能死锁。Rust的优势是把“谁能碰这块数据”变成编译器也能参与检查的契约。

CHAPTER 06

AI能搬代码，最危险的是它看起来已经搬完了

回到那35个软件。论文和项目README里，失败记录比成功数字更值得看。

作者写得很直接：朴素地让Claude迁移，常会漏掉大部分功能、忽略边界情况，把高级算法换成暴力实现。更麻烦的是，Agent生成的测试也可能只覆盖它自己刚写出的简化版本；做性能对比时，还可能给Rust开8个线程，却让原C程序只跑1个线程。

所以他们后来强调静态分析、函数尽量一一对应、尽早上真实数据，并把任何性能偏差——无论变快还是变慢——先当作回归来查。VTK迁移经过数天系统审计后，真实数据仍继续找出错误。

这是科研软件迁移必须守住的一道线：编译通过只是第一步；输出看着像，也不等于迁移已经完成。 旧版与新版是否在已知答案、边界数据、数值误差和真实样本上保持一致，必须单独验证。性能比较要排在等价性之后。

CHAPTER 07

你什么时候该考虑Rust

如果你在维护命令行工具、解析器、网络服务、数据库组件或长期运行的数据管道，项目又同时在意跨平台、资源占用、并发和内存安全，Rust值得进入候选名单。尤其是那些“运行次数很多、出错代价很高、未来还要交给别人维护”的核心模块。

如果任务还在快速探索，主要价值来自Python/R现成的科学库，团队也没有人愿意承担Rust学习成本，那就别急着整仓重写。更现实的做法，是先挑性能瓶颈、脆弱的C/C++边界或需要独立分发的CLI，把它们改成Rust，再通过Python扩展或C ABI接回原系统。

FFI不是免费的安全通道。Rust官方文档把外部函数调用放进unsafe，因为编译器无法确认C函数签名、裸指针和线程约束是否真的正确。边界越窄，审计越容易。

Rust最特别的，还是那个有点烦人的编译器。它不会替你判断科学问题，却会不停追问数据归谁、谁能改、能活多久。

一段软件如果准备维护十年，这些问题越早回答，代价越低。

REFERENCE

参考来源

Rust官方网站｜https://www.rust-lang.org/
The Rust Programming Language：Ownership与Borrowing｜https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html
Cargo Book｜https://doc.rust-lang.org/cargo/
预印本 arXiv:2608.13029｜https://arxiv.org/abs/2608.13029
Rustification项目仓库｜https://github.com/henriksson-lab/rustification

CHAPTER 08