将 React Compiler 移植到 Rust

原文 ↗ Hacker News 讨论 ↗

React Compiler 的使用情况与真实世界性能

  • 多位评论者表示在生产环境中使用 React Compiler（例如大型电商/媒体网站、Unifi UI、中等规模应用）。
  • 反馈的收益包括：渲染性能明显更好，能够删除大多数 memo/useMemo/useCallback 而不引入回归，并且在至少一个案例中比之前的 Preact 方案表现更好。
  • 缺点：构建时间增加，不过也有人认为在现代 bundler 下编译时间可以接受；与某些库（例如 MobX）不兼容，导致至少有一家公司回滚，因为他们在现有代码库上也没有看到明确的性能提升。

自动 memoization 与安全性

  • 一些人对自动 memoization 持怀疑态度，因为它可能带来微妙的性能回归和隐藏依赖的风险。
  • 另一些人则描述了良好体验：ESLint 规则会标出无法优化或不符合 hook 规范的代码，不兼容的库会被自动排除，而且编译器生成的 memoization 比手写模式更细粒度，也更不容易出错。
  • 有人建议使用在线编译器 playground 等工具来查看代码是如何被转换的。

为什么选 Rust，以及移植如何工作

  • 当前编译器是用 TypeScript / Flow 写的；Rust 被视为一种获得速度、原生二进制、更容易并行化以及脱离 JS 运行时的方式。
  • 内存安全被承认为加分项，但大多数人认为原始性能和启动时间才是主要动机。
  • 使用 arenas 作为 GC 的替代方案；一些人认为这在概念上很简单，而不是增加复杂性。

AST 设计：Babel 还是 Oxc

  • 有人质疑为什么 Rust 版本保留了类似 Babel 的 AST，而不是采用 Oxc 的 AST。
  • 反对者的论点是：有多个消费者，团队已经围绕 Babel 的表示构建了逻辑，而且他们只想维护一个复杂的 AST→HIR 转换。生态系统范围的清理以后再做也可以。

LLM 辅助的 Rust 移植：信任、测试与可维护性

  • 许多人认为这次移植大量借助了 LLM，并认为这很适合在有强测试套件的情况下进行机械式重写。
  • 支持者表示：如果它通过了数千个测试（再加上新的测试），且公共 API 不变，那就是务实的胜利；LLM 擅长“比较结果、修复、重复”这种迭代过程。
  • 怀疑者认为：12 万行级别的 PR 几乎无法被人类审查；“测试通过”可能掩盖漏洞；如果很少有人真正深入理解代码，那么未来的功能开发可能会有风险。
  • 还有人担忧“认知债务”，以及代码库最终实际上只能借助 LLM 才能维护的趋势。

流程、评审与更广泛的反思

  • 有人担心大型 PR 公开可见的评审有限，而且与过去的 React 里程碑相比，公开 RFC 更少。
  • 也有人回应说，语言选择只是实现细节，而 React 的公开契约保持稳定。
  • 更广泛的争论包括：动态语言与静态语言、Java/.NET 与 Go/Rust 原生工具，以及 LLM 是否降低了，甚至“消除了”使用 Rust 这类复杂语言的门槛。