編程屆泰斗、流行編程語言 C# 和 TypeScript 主要設計者 Anders Hejlsberg 于 3 月 11 日在微軟技術博客上發布的文章^[1]可謂是一石激起千層浪：“我們開源了已經完成得差不多的 TypeScript-7 的代碼...不再使用 TypeScript 實現，而是將其遷移到了 go 語言...性能比現有 tsc 快了 10 倍，無論是編譯還是在 Language Server Protocol （LSP）上”。

基于編程經驗以及對技術社區的關注，在我的認知里，這個消息無疑是令人震驚的，在 Hacker News comments^[2] 和 Github disscussion^[3] 上的激烈討論也印證了我的觀點。

我的第一反應是：為什么不用 Rust ？

• Rust 幾乎已經全面“侵入” TypeScript 和前端生態鏈，比如編譯 TS 的 SWC 、 Oxc ，打包工具 Rolldown 、 Turbopack ，代碼檢查工具 RSLint 、 deno_lint
• 很巧的是，就在這個新聞出現前一天 3 月 10 日，我剛剛在茶余飯后聽了尤雨溪最新演講^[4]

2025 尤雨溪最新演講：圍繞 Vite 的前端統一工具鏈

結合我平時刷的前端帖子，仿佛一切都預示著：所有基于 JS/TS 實現的相對底層的工具，都將遷移到 Rust 實現...

但是當我看完 A 10x faster TypeScript 這個 13 分鐘的視頻，才發現選擇 Go ，而不是 Rust 或 C# 的理由是十分充分的。

我這個年代的程序員（23年畢業時， Go 生態已經相對成熟，已經被廣泛用于生產環境）在學習工作中已經有大量機會接觸到 Go ：

• MIT6.824 麻省理工的分布式系統公開課，作業和課程設計是基于 Go 語言的
• 在云原生時代，你不可能接觸不到 k8s ，而實現一些 hook ，要會用 Go 語言
• 相比 Java ， Go 的設計更加簡單、直接、底層——

Go 天生為服務端并發而服務，創建管理有棧協程 goroutine 極其方便

Go 的設計十分謹慎，不希望給程序員留出太多自我發揮的空間，從而嚴格控制了代碼質量：強類型、用大小寫規定變量私有公有屬性、 lint 不對就不許通過編譯 etc.

Go 拋棄了 OOP 面向對象編程，鼓勵使用 interface

Go 甚至只允許在函數中返回 err 拋棄了 try catch 機制

Go 甚至直接用 Git 倉庫管理依賴

Go 中可以直接訪問指針，某種意義上講可以把 Go 理解為有語法糖的 C 語言，但同時 Go 是有 GC 垃圾回收機制的

Go 可以直接打包 runtime ，把自己編譯成一個很小的可執行文件，并不需要管理生產環境運行時

上述特點也包含了 TypeScript 官方團隊選擇 Go 關鍵因素：

1. 他們需要程序很快， Go 天生并發
2. 他們需要 TypeScript 兼容各個平臺， Go 作為一個實現了 docker 這種 IoT 物聯網行業都廣泛應用的工具的語言，其兼容性已經得到證明
3. 他們需要有 GC 垃圾回收機制的語言（這點后面會展開解釋）

說到這里，肯定有人會問為什么不用同樣速度快、且更加底層并且和 TypeScript 生態耦合緊密的 Rust 呢？

因為 TypeScript 決定“移植”項目，而非“重構”項目。

如視頻中的一個截圖，已經可以很明顯地看出原因：

go 和 ts 的代碼幾乎一樣...

TypeScript 編譯器同一個函數邏輯，上圖左邊是 Go 實現，右邊是 TypeScript 實現，你可以發現，他們幾乎長得一樣...這也為 TypeScript-go 的開發工作減輕了極多的負擔。

如果使用 Rust ，考慮到 Rust 的設計哲學，則不得不進行重構。

實際上，在我翻之前收藏的知乎帖子時，才發現基于 Rust 實現 swc 工具的作者，前些日子也宣布了決定從 Rust 轉向 Go 。

https://www.zhihu.com/question/513453040/answer/2393678735

這其中的核心論點都是：并不是 Rust 不好，而是 Go 很方便。

另一個觀點是，為什么不用 C# 呢？要知道 TypeScript 和 C# 都是微軟設計并主導發展的技術，而 Go 則是對家 Google 的產品。尤其是 Anders Hejlsberg 還有 “TypeScript 和 C# 之父”的美名，“親爹”都不喜歡“親兒子”了嗎？

這里我總結一些觀點：

1. C# 和 Java / Python 類似，需要先轉為字節碼，運行在運行時上
2. 但是 C# 也可以 Native AOT 作為二進制執行呀？很簡單，正是由于 C# 什么都能做，導致其 Native AOT 并不如 Go 那般久經沙場考驗，這里還可以搬出 docker 的例子...
3. C# 主打 OOP 風格，與 TypeScript 項目本身的設計不一致，還是那句話：要移植而非重構

此外， Hejlsberg 老人家已經很久沒有管理過 C# 的發展了——現在的 C# 可以說和 C++ 一樣都是編程語言中的龐然巨獸，怪物般的存在。你可以用他們寫出風格特異甚至詭異的代碼。但是這本身是一柄雙刃劍，太強大以至于難以駕馭。

https://zhuanlan.zhihu.com/p/368304027

上述文章惡意并不強（并不是抨擊 Go ，而是抨擊無腦吹捧的風氣），其實可以說明 C# 在性能實現層面是高于 Go 的——但是 Go 的性能可能差一點點，而上手開發以及維護難度卻好了很多。

微軟的項目沒有刻意選擇應用自己的技術，恰恰說明其決策之純粹，是只基于技術層面的考量。 這種獨屬于技術引領者的、釋然放松的狀態，我們恐怕無論在主觀上還是在客觀上，都需要很長時間才能體會到。

所以從這里，我們可以總結出哪些經驗？

1. 開發成本是最需要考量的因素，這其中包括但不限于：技術選型的難度、開發路線是否曲折、生態是否良好、是否已經被實際證明可用、是否好找到幫手
2. 遠離編程語言飯圈，沒有一門語言值得被神化，客觀看待網絡觀點

同時，我也有一個小小疑問：Go 的 err 和類型系統在我看來是十分簡陋的，它能適配有“類型體操藝術家”之名的 TypeScript 嗎？答案一定就在整個 Repo 里。

參考資料

[1]在微軟技術博客上發布的文章: https://devblogs.microsoft.com/TypeScript/TypeScript-native-port/

[2]Hacker News comments: https://news.ycombinator.com/item?id=43332830

[3]Github disscussion: https://github.com/microsoft/TypeScript-go/discussions/411

[4]尤雨溪最新演講: https://www.bilibili.com/video/BV1WERGYDEix