技術(shù)選型之爭：看編程泰斗給 TypeScript-7 編譯器選型 Go 的淺顯思考與疑惑
編程屆泰斗、流行編程語言 C# 和 TypeScript 主要設(shè)計者 Anders Hejlsberg 于 3 月 11 日在微軟技術(shù)博客上發(fā)布的文章[1]可謂是一石激起千層浪：“我們開源了已經(jīng)完成得差不多的 TypeScript-7 的代碼...不再使用 TypeScript 實現(xiàn)，而是將其遷移到了 go 語言...性能比現(xiàn)有 tsc 快了 10 倍，無論是編譯還是在 Language Server Protocol （LSP）上”。
基于編程經(jīng)驗以及對技術(shù)社區(qū)的關(guān)注，在我的認(rèn)知里，這個消息無疑是令人震驚的，在 Hacker News comments[2] 和 Github disscussion[3] 上的激烈討論也印證了我的觀點。
我的第一反應(yīng)是：為什么不用 Rust ？
- Rust 幾乎已經(jīng)全面“侵入” TypeScript 和前端生態(tài)鏈，比如編譯 TS 的 SWC 、 Oxc ，打包工具 Rolldown 、 Turbopack ，代碼檢查工具 RSLint 、 deno_lint
- 很巧的是，就在這個新聞出現(xiàn)前一天 3 月 10 日，我剛剛在茶余飯后聽了尤雨溪最新演講[4]
2025 尤雨溪最新演講：圍繞 Vite 的前端統(tǒng)一工具鏈
結(jié)合我平時刷的前端帖子，仿佛一切都預(yù)示著：所有基于 JS/TS 實現(xiàn)的相對底層的工具，都將遷移到 Rust 實現(xiàn)...
但是當(dāng)我看完 A 10x faster TypeScript 這個 13 分鐘的視頻，才發(fā)現(xiàn)選擇 Go ，而不是 Rust 或 C# 的理由是十分充分的。
我這個年代的程序員（23年畢業(yè)時， Go 生態(tài)已經(jīng)相對成熟，已經(jīng)被廣泛用于生產(chǎn)環(huán)境）在學(xué)習(xí)工作中已經(jīng)有大量機會接觸到 Go ：
- MIT6.824 麻省理工的分布式系統(tǒng)公開課，作業(yè)和課程設(shè)計是基于 Go 語言的
- 在云原生時代，你不可能接觸不到 k8s ，而實現(xiàn)一些 hook ，要會用 Go 語言
- 相比 Java ， Go 的設(shè)計更加簡單、直接、底層——
Go 天生為服務(wù)端并發(fā)而服務(wù)，創(chuàng)建管理有棧協(xié)程 goroutine 極其方便
Go 的設(shè)計十分謹(jǐn)慎，不希望給程序員留出太多自我發(fā)揮的空間，從而嚴(yán)格控制了代碼質(zhì)量：強類型、用大小寫規(guī)定變量私有公有屬性、 lint 不對就不許通過編譯 etc.
Go 拋棄了 OOP 面向?qū)ο缶幊?，鼓勵使?interface
Go 甚至只允許在函數(shù)中返回 err 拋棄了 try catch 機制
Go 甚至直接用 Git 倉庫管理依賴
Go 中可以直接訪問指針，某種意義上講可以把 Go 理解為有語法糖的 C 語言，但同時 Go 是有 GC 垃圾回收機制的
Go 可以直接打包 runtime ，把自己編譯成一個很小的可執(zhí)行文件，并不需要管理生產(chǎn)環(huán)境運行時
上述特點也包含了 TypeScript 官方團隊選擇 Go 關(guān)鍵因素：
- 他們需要程序很快， Go 天生并發(fā)
- 他們需要 TypeScript 兼容各個平臺， Go 作為一個實現(xiàn)了 docker 這種 IoT 物聯(lián)網(wǎng)行業(yè)都廣泛應(yīng)用的工具的語言，其兼容性已經(jīng)得到證明
- 他們需要有 GC 垃圾回收機制的語言（這點后面會展開解釋）
說到這里，肯定有人會問為什么不用同樣速度快、且更加底層并且和 TypeScript 生態(tài)耦合緊密的 Rust 呢？
因為 TypeScript 決定“移植”項目，而非“重構(gòu)”項目。
如視頻中的一個截圖，已經(jīng)可以很明顯地看出原因：
go 和 ts 的代碼幾乎一樣...
TypeScript 編譯器同一個函數(shù)邏輯，上圖左邊是 Go 實現(xiàn)，右邊是 TypeScript 實現(xiàn)，你可以發(fā)現(xiàn)，他們幾乎長得一樣...這也為 TypeScript-go 的開發(fā)工作減輕了極多的負(fù)擔(dān)。
如果使用 Rust ，考慮到 Rust 的設(shè)計哲學(xué)，則不得不進行重構(gòu)。
實際上，在我翻之前收藏的知乎帖子時，才發(fā)現(xiàn)基于 Rust 實現(xiàn) swc 工具的作者，前些日子也宣布了決定從 Rust 轉(zhuǎn)向 Go 。
https://www.zhihu.com/question/513453040/answer/2393678735
這其中的核心論點都是：并不是 Rust 不好，而是 Go 很方便。
另一個觀點是，為什么不用 C# 呢？要知道 TypeScript 和 C# 都是微軟設(shè)計并主導(dǎo)發(fā)展的技術(shù)，而 Go 則是對家 Google 的產(chǎn)品。尤其是 Anders Hejlsberg 還有 “TypeScript 和 C# 之父”的美名，“親爹”都不喜歡“親兒子”了嗎？
這里我總結(jié)一些觀點：
- C# 和 Java / Python 類似，需要先轉(zhuǎn)為字節(jié)碼，運行在運行時上
- 但是 C# 也可以 Native AOT 作為二進制執(zhí)行呀？很簡單，正是由于 C# 什么都能做，導(dǎo)致其 Native AOT 并不如 Go 那般久經(jīng)沙場考驗，這里還可以搬出 docker 的例子...
- C# 主打 OOP 風(fēng)格，與 TypeScript 項目本身的設(shè)計不一致，還是那句話：要移植而非重構(gòu)
此外， Hejlsberg 老人家已經(jīng)很久沒有管理過 C# 的發(fā)展了——現(xiàn)在的 C# 可以說和 C++ 一樣都是編程語言中的龐然巨獸，怪物般的存在。你可以用他們寫出風(fēng)格特異甚至詭異的代碼。但是這本身是一柄雙刃劍，太強大以至于難以駕馭。
https://zhuanlan.zhihu.com/p/368304027
上述文章惡意并不強（并不是抨擊 Go ，而是抨擊無腦吹捧的風(fēng)氣），其實可以說明 C# 在性能實現(xiàn)層面是高于 Go 的——但是 Go 的性能可能差一點點，而上手開發(fā)以及維護難度卻好了很多。
微軟的項目沒有刻意選擇應(yīng)用自己的技術(shù)，恰恰說明其決策之純粹，是只基于技術(shù)層面的考量。 這種獨屬于技術(shù)引領(lǐng)者的、釋然放松的狀態(tài)，我們恐怕無論在主觀上還是在客觀上，都需要很長時間才能體會到。
所以從這里，我們可以總結(jié)出哪些經(jīng)驗？
- 開發(fā)成本是最需要考量的因素，這其中包括但不限于：技術(shù)選型的難度、開發(fā)路線是否曲折、生態(tài)是否良好、是否已經(jīng)被實際證明可用、是否好找到幫手
- 遠離編程語言飯圈，沒有一門語言值得被神化，客觀看待網(wǎng)絡(luò)觀點
同時，我也有一個小小疑問：Go 的 err 和類型系統(tǒng)在我看來是十分簡陋的，它能適配有“類型體操藝術(shù)家”之名的 TypeScript 嗎？答案一定就在整個 Repo 里。
參考資料
[1]在微軟技術(shù)博客上發(fā)布的文章: 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
