用地道 Rust 重写的 Linux 0.11，已能在 QEMU 中启动

原文 ↗ Hacker News 讨论 ↗

一个早期的 Linux 0.11 内核已被用地道的 Rust 重写，并成功在 QEMU 中启动，引发了关于代码规模、可读性，以及 Rust 的安全性和抽象是否值得额外复杂度的争论。许多人怀疑大量代码由 AI 生成，这又引出了对这类重写在教育价值、真实性和长期可维护性方面的疑问。更广泛地说，评论者围绕在 LLM 辅助下将现有 C 和 Zig 代码库“Rust 化”的日益流行趋势展开争论，在内存安全与现代化之间，对照的是炒作、工具依赖和文化疲劳。

重写范围与行数

  • 评论者指出，与原始 C 源码相比，这个 Rust 仓库的行数多得多（最初约 5 万行，而原版约 8–12 千 SLOC）。
  • 也有人指出：
    • 一份拆分显示内核部分约有 1.5 万行；其余是工具、实用程序和用户态程序。
    • Rust 中的注释、测试以及额外抽象也增加了规模。
    • 关于冗长程度存在争论：有人认为 Rust 更明确、更啰嗦；也有人说，对于等价功能，Rust 可以和 C 一样简洁，甚至更短。

AI 参与与“slopware”担忧

  • 多位评论者怀疑很大一部分是由 LLM 生成的（依据是 README 风格、表情符号，以及“地道抽象”之类的措辞）。
  • 有些人认为这没问题，甚至对一个玩具/概念验证项目来说是理想的，毕竟没人会在生产环境里运行它。
  • 也有人对 AI 生成的“token 项目”感到沮丧，认为这只是低投入的自我宣传，不如人类亲手重写来得令人印象深刻。
  • 还有人担心，AI 重写往往只是把不安全模式搬进“unsafe Rust”，并没有真正带来安全收益。

Rust 的地道性、可读性与安全性

  • 一些评论者觉得 Rust 分支的实现对于某些系统调用（例如 fork）来说，和 C 相比相似，甚至更短。
  • 另一些人则批评 Rust 版本“繁琐”：
    • 许多行用于抽象、错误处理或语言限制，而不是核心逻辑。
    • 大量嵌套闭包和复杂的类型推断被认为损害可读性，并且需要很强的工具支持。
  • 支持者认为，Rust 明确的枚举、类型和借用检查可以减少一类错误，因此值得进行重写。

项目的目的与价值

  • 大家普遍承认这是一个玩具/教育/概念验证性质的努力（Linux 0.11 在今天并没有实际用途）。
  • 有些人认为其价值在于：
    • 展示内核可以被“Rust 化”。
    • 探索 AI 辅助的大规模重写及其工作流。
  • 另一些人则认为，如果大部分代码都是 LLM 写的，教育价值就打了折扣。

更广泛的 Rust 与 LLM 反弹情绪

  • 有几条评论表达了对以下现象的疲惫：
    • 不断出现的“X 用 Rust 重写了”的公告。
    • Rust 布道与 AI 生成重写的结合。
  • 反方观点强调：
    • Rust 在取代不安全 C 方面的作用日益增长，包括用户态和内核。
    • 实验性和“好玩”的副项目仍应受到鼓励。