吵翻了！TypeScript 官方編譯器移植到 Go 語言，為什么不是 Rust / C# ?!
TypeScript（簡稱 TS）社區最近炸開了鍋！官方宣布將 TS 編譯器從 JavaScript（JS）移植到 Go 語言，號稱性能提升10倍。這一消息一出，開發者們的情緒像是過山車：有人拍手叫好，覺得這波操作務實又高效；有人卻滿臉問號，甚至有點受傷——“為啥不是 Rust？為啥不選 C#？”畢竟，TS 的靈魂人物 Anders Hejlsberg 可是 C# 的締造者，而 Rust 在 JS/TS 生態中早已是“性能先鋒”的代名詞。這到底是怎么回事？讓我們一探究竟！
10倍性能提升，Go 成“救世主”
先來看看這次移植的亮點。TS 官方在博客《A 10x Faster TypeScript》中明確表示，新的 Go 版編譯器（代號“Corsa”）將大幅提升開發者體驗。無論是命令行構建還是編輯器加載速度，都能實現10倍左右的加速。以 Visual Studio Code（VS Code）這個擁有150萬行代碼的龐然大物為例，原先用 JS 版編譯器（tsc）檢查全項目要77.8秒，現在 Go 版只用7.5秒，足足快了10.4倍！編輯器加載時間也從9.6秒驟降到1.2秒，內存占用還減半。這波優化，直接讓大型項目的開發者從“等得花兒都謝了”變成了“快到飛起”。
TS 團隊的核心訴求很明確：他們希望編譯器能快速啟動、快速完成任務，同時保持與現有 JS 代碼庫的高度兼容。項目負責人 Ryan Cavanaugh 在 GitHub 討論中寫道：“我們需要新代碼在語義和結構上盡量貼近現有代碼，這樣才能同時維護兩套代碼庫。”這意味著，這次不是從零開始的重寫，而是一次“搬家式移植”。Go 之所以脫穎而出，是因為它的代碼風格與 TS 現有的函數式+數據結構模式高度吻合，用 Go 寫出來的代碼幾乎像是 JS 版的“鏡像”，開發者改動時可以輕松在兩邊同步。
除此之外，Go 的內存管理也幫了大忙。TS 編譯器需要大量處理抽象語法樹（AST）等數據結構，這些對象生命周期較長，而 Go 的垃圾回收（GC）機制正好能簡化代碼復雜度。Anders Hejlsberg 在采訪中提到：“Go 是最接近原生代碼的語言，同時還自帶自動垃圾回收。”相比之下，手動管理內存會讓移植工作量翻倍，而 TS 團隊顯然不想給自己找這個麻煩。
Rust：生態寵兒為何落選？
然而，看到 Go 被選中，Rust 的粉絲坐不住了。畢竟，在 JS/TS 生態中，Rust 早已是“性能擔當”的代表。像 SWC、OXC、esbuild（雖然是用 Go 寫的）這樣的工具，都在用 Rust 或 Go 大幅提升構建速度。Rust 以其內存安全和強大的類型系統著稱，尤其擅長處理編譯器這種需要大量遍歷樹結構的場景。社區里有人直言：“Rust 的 match 語法簡直是為解析器和 AST 遍歷量身定做的，Go 能比得上嗎？”
對此，TS 團隊的回應很直接。Ryan Cavanaugh 在 FAQ 中解釋：“如果是從頭重寫，Rust 確實是個好選擇。但我們這次是移植，需要保留現有行為的精確性。”Rust 的零成本抽象和嚴格的借用檢查雖然強大，卻要求開發者重新設計內存管理邏輯，這與 TS 當前基于 GC 的代碼風格格不入。Anders Hejlsberg 在視頻采訪中補充道：“Rust 沒有垃圾回收，我們得重構所有數據類型，這太費勁了。”換句話說，Rust 的理想主義雖美，但在這次務實的“搬家”任務面前，顯得有點“水土不服”。
還有個現實問題：Rust 的學習曲線陡峭。Go 的簡單語法讓新手也能快速上手，這對開源項目的貢獻者友好度是個加分項。一名網友在 Hacker News 上調侃：“Rust 粉絲別急，TS 團隊只是想快點干完活，而不是花半年研究生命周期。”雖然有點夸張，但也道出了部分真相——TS 團隊更看重效率和兼容性，而非追求極致的性能潛力。
C#：Anders 的“親兒子”為何被冷落？
如果說 Rust 落選還能理解，那 C# 被排除在外就讓很多人摸不著頭腦了。Anders Hejlsberg 是 C# 的創始人，TS 又是微軟的項目，按理說用 C# 既能“肥水不流外人田”，還能統一微軟的開發敘事。部分 C# 支持者甚至感到被背叛：“Anders 你這是不愛自己的孩子了嗎？”還有人感嘆：“C# 的 Roslyn 編譯器都用 C# 寫得那么成功，為什么 TS 不跟上？”
TS 團隊的理由依然圍繞“移植便利性”。Ryan Cavanaugh 表示：“C# 的面向對象風格和 TS 現在的函數式代碼不太搭。”TS 編譯器的 JS 版幾乎全是函數和數據結構，幾乎沒有類，而 C# 的習慣用法更偏向 OOP（面向對象編程）。Anders 在采訪中進一步解釋：“Go 比 C# 更低級，它的結構體和內聯數據表達能力更接近 JS 的風格。”他還提到，C# 雖然有 AOT（提前編譯）選項，但這些功能跨平臺支持不夠成熟，遠不如 Go 的靜態單二進制文件來得直接。
社區里也有聲音質疑這種說法。一名 Hacker News 用戶指出：“C# 有 record、靜態方法和 Span，完全可以映射 TS 的數據結構，Anders 這理由有點牽強。”還有人猜測，背后可能是團隊偏好或政治因素：“Go 在微軟內部越來越流行，連 Dapr 框架都用它，C# 是不是被邊緣化了？”不過，Anders 本人澄清道：“這不是對 C# 的否定，微軟內部 C# 仍是主流。這只是針對 TS 的特定需求做出的選擇。”
吵歸吵，開發者體驗才是王道
這場語言之爭吵得熱火朝天，但 TS 團隊的態度很明確：他們不在乎“語言信仰”，只想用最合適的工具解決問題。Go 的勝利不是因為它完美無缺——比如它與 JS 的互操作性就比不上 Rust 或 C#——而是因為它在這次移植中平衡了性能、兼容性和開發效率。TS 團隊甚至承諾會優化 Go 的 JS API，確保生態工具不會因為這次遷移而翻車。
對于普通開發者來說，這場爭論的意義可能沒那么大。無論編譯器是用 Go、Rust 還是 C# 寫的，最終輸出的還是 JS 代碼，運行時性能不會有變化。真正的好處是構建更快、編輯器更流暢。正如一名網友總結：“10倍加速都擺在面前了，還在乎用什么語言寫？趕緊用起來吧！”
未來展望：TS 7.0 會帶來什么？
按照官方計劃，Go 版編譯器將在 TypeScript 7.0 中正式亮相，而 JS 版會繼續維護到 6.x 系列穩定。這意味著短期內開發者可以自由選擇版本，長期來看則會逐步過渡到 Go 版。TS 團隊還透露，新編譯器將支持更高級的重構功能和 AI 工具集成，這些都得益于性能的飛躍。
至于 Rust 和 C# 的粉絲們，或許可以期待下一次機會。畢竟，Anders Hejlsberg 也說了：“如果是個全新項目，語言選擇會完全不同。”但眼下，Go 已經接過了接力棒，帶著 TS 邁向更快的未來。你怎么看這次選擇？歡迎留言吵一架——畢竟，程序員不吵架，還叫程序員嗎？
Ref:
