技術選型之爭：看編程泰斗給 TypeScript-7 編譯器選型 Go 的淺顯思考與疑惑
編程屆泰斗、流行編程語言 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 關鍵因素：
- 他們需要程序很快， Go 天生并發
- 他們需要 TypeScript 兼容各個平臺， Go 作為一個實現了 docker 這種 IoT 物聯網行業都廣泛應用的工具的語言，其兼容性已經得到證明
- 他們需要有 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# 之父”的美名，“親爹”都不喜歡“親兒子”了嗎？
這里我總結一些觀點：
- C# 和 Java / Python 類似，需要先轉為字節碼，運行在運行時上
- 但是 C# 也可以 Native AOT 作為二進制執行呀？很簡單，正是由于 C# 什么都能做，導致其 Native AOT 并不如 Go 那般久經沙場考驗，這里還可以搬出 docker 的例子...
- C# 主打 OOP 風格，與 TypeScript 項目本身的設計不一致，還是那句話：要移植而非重構
此外， Hejlsberg 老人家已經很久沒有管理過 C# 的發展了——現在的 C# 可以說和 C++ 一樣都是編程語言中的龐然巨獸，怪物般的存在。你可以用他們寫出風格特異甚至詭異的代碼。但是這本身是一柄雙刃劍，太強大以至于難以駕馭。
https://zhuanlan.zhihu.com/p/368304027
上述文章惡意并不強（并不是抨擊 Go ，而是抨擊無腦吹捧的風氣），其實可以說明 C# 在性能實現層面是高于 Go 的——但是 Go 的性能可能差一點點，而上手開發以及維護難度卻好了很多。
微軟的項目沒有刻意選擇應用自己的技術，恰恰說明其決策之純粹，是只基于技術層面的考量。 這種獨屬于技術引領者的、釋然放松的狀態，我們恐怕無論在主觀上還是在客觀上，都需要很長時間才能體會到。
所以從這里，我們可以總結出哪些經驗？
- 開發成本是最需要考量的因素，這其中包括但不限于：技術選型的難度、開發路線是否曲折、生態是否良好、是否已經被實際證明可用、是否好找到幫手
- 遠離編程語言飯圈，沒有一門語言值得被神化，客觀看待網絡觀點
同時，我也有一個小小疑問：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
