TypeScript 为什么使用 Go 而不是 Rust 重写 ？官方回应来了

TypeScript官推最近宣布他们正在移植到 Go，速度已经提高了 10 倍之多。

作为以性能为代表的另一语言Rust，人们自然会疑惑为什么没有选Rust语言重构呢？为方便大家快速理解，我用DeepSeek用小红书的语气重新总结了下：（原文放在下方，大家可以继续往下阅读）

【技术选型大实话！Go vs Rust我站它】

家人们谁懂啊！做技术选型真的太难了当初在Go和Rust之间反复横跳，最后含泪总结出这些干货

核心结论：
Go移植TS代码真香警告！1年肝出高兼容+高性能版本 vs Rust重写可能耗3年还难用（大冤种预警.jpg）

划重点理由：
1️⃣ 移植舒适度拉满
Rust移植JS/TS就像把大象塞冰箱疯狂踩坑+写unsafe代码预警！Go却能丝滑复刻原代码结构，开发者头发保住啦♀️

2️⃣ 性能焦虑退退退
实测单核性能差不离！Go不用魔改unsafe就能打，内存管理还贼懂事（疯狂暗示内存条不用燃烧）

3️⃣ 隐藏彩蛋get
选Go还能自动屏蔽"为啥不用Rust"的灵魂拷问（懂的都懂.jpg）而且API接口照样能玩出花，根本不care互操作短板~

️暴言预警：
Rust虽强但移植JS不是它KPI啊！就像要求程序员会修电脑——专业不对口嘛！Go恰巧对上咱们的移植DNA

最后暴风夸夸：
Go的代码生成能力绝绝子！并发原语和Rust五五开，写起来还像喝奶茶一样顺滑TS代码人原地搬家不是梦~

原文声明翻译：

我们在选择 Go 时就明确知道，肯定会有人质疑我们为什么没有选择 Rust。这是一个很好的问题，因为 Rust 是一门出色的语言，如果没有其他限制，它在编写新的原生代码时是一个很强的首选。

可移植性（即能够创建一个与当前代码库算法上相似的新代码库的能力）一直是我们考虑如何实现这一目标时的关键限制。我们尝试了大量方法，试图找到一种在 Rust 中可行的表示方式来实现这种移植，但所有方法要么存在不可接受的权衡（性能、人机工程学等），要么演变成了“自己编写垃圾回收器”式的策略。有些方法几乎成功了，但往往需要大量使用不安全代码，而 Rust 中似乎没有多少基础元素的组合能够让人机工程学上轻松地将 JavaScript 代码移植过来（这样说并不令人意外——大多数语言并不优先考虑让从 JavaScript/TypeScript 移植变得容易！）。

最终，我们面临两个选择——在 Rust 中从头开始完全重写，这可能需要数年时间，并产出一个与 TypeScript 不兼容、无人能实际使用的版本；或者在 Go 中进行移植，大约一年左右就能得到一个可用的东西，在语义上高度兼容，在性能上极具竞争力。

而且，我们甚至不太清楚这么做的好处是什么（除了不必应对那么多“你们为什么没选 Rust？”的问题）。我们仍然希望有一个高度分离的 API 接口，以保持我们实现选择的开放性，因此 Go 的互操作性短板并不是特别相关。Go 拥有出色的代码生成和数据表示能力，就像 Rust 一样。Go 拥有出色的并发原语，就像 Rust 一样。单核性能也在误差范围内。虽然在 Go 中使用不安全代码可能会带来一些性能提升，但我们在不使用任何不安全原语的情况下已经获得了出色的性能和内存使用。

在我们看来，Rust 在实现其设计目标方面非常成功，但“从这个特定的 JavaScript 代码库轻松移植到 Rust”显然不是它的设计目标之一。Go 也不是，但就我们目前编写代码的方式而言，它在这方面确实表现得相当不错。

关于贡献问题，我并不是特别担心。学习如何在类型检查器中正确工作所需的努力，远比学习 Go 要多得多。