Tsrs：TypeScript 的 Rust 移植版本

原文 ↗ Hacker News 讨论 ↗

Cloudflare 新的基于 Rust 的 TypeScript 编译器 tsrs，据称在大型项目上编译时间可比官方实现快 3–4 倍，内存占用约降低 70%；这部分得益于自定义的 arena 风格内存模型以及对 WebAssembly 的更好适配。评论者在实用收益——为大规模 CI 和 AI agent 工作流提供更便宜、更快的工具——与对不安全 Rust 模式的担忧，以及 AI 生成的“vibe coded”移植可能削弱人类精心打造的编译器之间权衡。许多人将其视为 Rust 与 WASM 在高性能开发者工具领域的又一次验证，也意味着语言工具生态很快可能并行维护多个 AI 辅助实现。

性能与基准测试

  • 声称相较于 TS 7.0 基线，速度最高可达约 8 倍，内存占用降低约 70%；一个具体例子是，VS Code 在 tsrs 中的编译速度比 TS 7/7.1 快约 3–4 倍。
  • 有人认为对许多项目而言，TS/TSGO 已经“足够快”；也有人报告了现实中的大幅收益（例如类型检查从 10 秒降到不足 0.5 秒、内存大幅下降），并指出对于大型 monorepo 以及高频 CI/agent 工作负载，这些节省会累积得很可观。

动机：WASM、Workers 与 Agents

  • 核心驱动力是在 Cloudflare 仅支持 WASM 的沙箱中运行整个工具链，而不必携带完整的 Go 运行时。
  • Rust 与 WASM 的适配度更高（没有 GC 运行时，二进制更小），这在大规模场景以及大量并发 AI agents/worktrees 下尤为重要。

Rust、Go 与其他实现

  • 最初选择 Go，是因为从带 GC 的代码库迁移更容易；随着 AI 辅助移植，这一理由变弱了。
  • 有人认为“理想”的分工是：TypeScript 作为参考实现；Rust 用于性能/WASM；而 Go 现在更像一种折中。
  • 也有人强调，语言选择对于长期的人类维护和开发体验仍然很重要。

AI 生成的移植与开发流程

  • 这次移植很大程度上由 AI 驱动，并以庞大的 TS 测试套件作为安全网。
  • 反应两极分化：一方面为快速移植感到兴奋，另一方面则担忧会失去精心设计、由人主导的架构和代码审查的价值。
  • 有人声称审查 AI 代码很快会成为浪费时间；也有人认为这种看法天真，强调人类持续监督仍然必要。

TypeScript 团队与生态影响

  • TS 团队正在与 tsrs 合作，将优化借鉴到 TS 7.1 中（如延迟工作、更好的分配/布局），并认识到速度提升不只是“Rust 对 Go”的结果，也来自算法改进。
  • 关于是否继续投资 TSGO 存在争论：支持 Rust 的观点强调其带来的 WASM 适配性和更高效率；反对者则突出稳定性、兼容性以及团队偏好。

内存模型与安全性担忧

  • tsrs 使用了 arena 风格分配和自定义的“fake GC”/回收方案。
  • 有人称赞这种做法；也有人批评其不安全的 'static 抽象和依赖 sanitizer 的验证方式“像回到了 C”，担心这会削弱 Rust 的安全保证。

元话题：Rust 重写、开源与 AI 疲劳

  • 对更广泛的“把一切都重写成 Rust”以及“vibe-coded” AI 移植潮，态度复杂。
  • 也有人担心，AI 驱动、更快的成熟项目分支会打击开源作者的积极性，因为他们会觉得自己的工作可以被廉价地取代。