微軟已經著手將 TypeScript 編譯器和工具集移植至 Go，旨在實現各類程式碼庫的 10 倍編譯速度提升。大部分開發者都覺得這是個好訊息。不過，也有一些人感到不解，他們想知道，為什麼微軟選擇了 Go 語言，而不是 Rust 語言來做這件事。
昨天，TypeScript 之父 Anders Hejlsberg 在一篇博文中宣佈，微軟已啟動一項計劃，將 TypeScript 編譯器和工具移植至代號為“Corsa”的原生 Golang 實現。透過這次原生實現，微軟承諾效能將提升 10 倍，同時增強開發者體驗，並引入全新的 AI 驅動功能。
Hejlsberg 表示，這項工作還解決了大型程式碼庫面臨的擴充套件性挑戰。TypeScript 使用者目前在處理大型程式碼庫時，往往面對載入時間過長、型別檢查緩慢以及記憶體限制等問題，因此開發者被迫在合理的編輯器啟動時間和獲取原始碼完整檢視之間做出選擇。
現在，透過將 TypeScript 編譯器移植到 Go 語言，微軟不僅提升了效能，還有效應對了擴充套件性挑戰。
關鍵效能提升包括：構建時間縮短約 10 倍，專案載入速度提升 8 倍，記憶體佔用減少至當前實現的大約一半（預計未來還將進一步最佳化）。此外，語言服務方面也有顯著改進，補全、快速資訊（quick info）、跳轉到定義以及查詢所有引用的速度均大幅提升。
“原生實現將顯著加快編輯器啟動速度，使大多數構建時間縮短 10 倍，並大幅降低記憶體佔用。”Hejlsberg 寫道。
新的原生版本在多個熱門程式碼庫上展現出了卓越的效能指標：
-
VS Code (1,505,000 LOC)： 77.8s → 7.5s（提升 10.4 倍）
-
Playwright (356,000 LOC)： 11.1s → 1.1s（提升 10.1 倍）
-
TypeORM (270,000 LOC)： 17.5s → 1.3s（提升 13.5 倍）
-
date-fns (104,000 LOC)： 6.5s → 0.7s（提升 9.5 倍）
-
tRPC (18,000 LOC)： 5.5s → 0.6s（提升 9.1 倍）
-
rxjs (2,100 LOC)： 1.1s → 0.1s（提升 11.0 倍）
效能提升 10 倍，這不僅僅是數字上的變化，它意味著 TypeScript 和 JavaScript 的開發體驗迎來了巨大飛躍。
以編輯器為例，大多數開發者的工作時間幾乎都在編輯器中度過，因此編輯器的效能至關重要。理想情況下，它應能快速載入大型專案，並在各種操作中保持流暢響應。而編輯器的核心效能很大程度上取決於底層語言服務的速度。藉助原生實現，TypeScript 的編輯體驗達到了前所未有的流暢度。
為了更具體地說明這一點，以 Visual Studio Code 程式碼庫為例，目前在高配置計算機上將完整專案載入至編輯器中的用時約為 9.6 秒。而使用原生語言服務之後，載入時間縮短至 1.2 秒左右，提升約 8 倍。
在解釋為何要更換語言時，Hejlsberg 指出，JavaScript（TypeScript 所基於的語言）主要用於 UI 和瀏覽器場景，而並不適用於編譯器或系統級工具等計算密集型工作負載。他補充道，微軟可能已經接近 JavaScript 效能最佳化的極限，“我們能從 JavaScript 中榨取的效能提升空間已經所剩無幾。”
在開發策略方面， Hejlsberg 表示，他們的團隊明確希望對 TypeScript 編譯器進行移植（port），而不是完全重寫（rewrite）成 Go。
在 TypeScript 專案的常見問題解答（FAQ）中，TypeScript 團隊的開發負責人 Ryan Cavanaugh 進一步解釋說，在更換程式語言時，通常有兩種策略可選。一是重寫（rewrite）， 從零開始實現一個新的系統，目標是解決與原系統相同的問題，但不考慮原有程式碼庫的實現方式。二是移植（port），以現有程式碼庫為基礎，將其轉換為新的語言，同時儘可能保持原有架構和邏輯不變。而移植的執行速度更快，但前提是新語言在架構上與原語言至少有一定的相容性。
Hejlsberg 表示，微軟曾嘗試用 C#、C++、Rust 等常見候選語言進行原型開發，但最終發現 Go 最適合他們的特定工作負載。
Arcjet CEO David Mytton 在接受媒體採訪時表示：
“非常有趣！JS 開發者早已習慣了慢速的工具，因此一個能加快編輯器啟動時間的高速編譯器無疑是個好訊息。遷移到原生編譯器是合理的選擇，儘管 Go 作為這一類專案的實現語言有些不太常見。看到這個公告時，我本以為他們會像其他 JS 工具重寫專案那樣選擇 Rust，比如 Rolldown、Turbo（從 Go 遷移到 Rust）、Deno……我很好奇他們做出這一決策的原因。”
對於這個問題，Cavanaugh 在 FAQ 中回應稱，考慮到多個特定因素，Go 仍然是最優選擇。
“最關鍵的一點是，我們需要儘可能保持新程式碼庫的相容性，無論是在語義層面還是程式碼結構上。” 他寫道，“我們預計未來相當長一段時間內會同時維護兩個程式碼庫，因此能夠保持結構相似的語言對於程式碼遷移和維護極為有利，因為這樣我們可以更輕鬆地在兩個程式碼庫之間同步變更……”
基於 Go 的 TypeScript 實現現已在 GitHub（https://github.com/microsoft/typescript-go）開源，並已能夠載入多個主流 TypeScript 專案，包括 TypeScript 編譯器自身。
有網友好奇，微軟 TypeScript 團隊在最終選擇 Go 語言之前，到底嘗試了 Rust 多久？畢竟 Rust 以效能和安全性著稱。有人調侃說：“我聽說他們幾乎撐過了午飯時間才換的。” 這句話可能暗示 TypeScript 團隊並沒有對 Rust 進行多麼深入的嘗試。
事實上，不少人對此決定感到不解，他們想知道，為何微軟最終沒選 Rust。這種疑惑和不解的情緒，在社交媒體上尤為明顯。正如一位 X 網友所言：“比 TypeScript 實現 10 倍提速更令人震驚的是，他們竟然沒有選擇 Rust。”
另一位使用者更是直言，“轉眼間，Java 與 C# 誰更好的戰火就蔓延到了 Rust 和 Go 這邊。感謝 TypeScript 煽動了這場紛爭。”
顯然，TypeScript 團隊的選擇在開發者社群中引發了關於程式語言選擇的激烈討論。更有甚者，有使用者以幽默的方式表達了對 Rust 擁躉的看法，“為什麼 Rust 狂熱者在 TypeScript 選擇 Go 重寫編譯器時哭泣？因為他們無法接受 Go 在不需要生命週期保證的情況下也能搶走風頭！”
隨著不滿情緒的出現，TypeScript 首席開發者 Ryan Cavanaugh 出面做出澄清，承認他們已經預料到開發者社群就會此展開爭論。
他提到，雖然 Rust 也是個不錯的選擇，但“決定性因素”在於可移植性，即如何確保新程式碼庫在演算法上與當前程式碼庫保持一致。
他還透露，TypeScript 團隊探索了多種方法來表示程式碼，檢驗用 Rust 重寫程式碼是否可行。但其在效能和開發體驗等方面帶來了“不可接受的”問題。某些方案需要單獨實現垃圾收集器（GC），這會增加額外的複雜性。
與之形成鮮明對比的是，Go 語言具備記憶體自動回收機制，即所謂“垃圾收集”。Cavanaugh 坦言，“雖然二者中的某些機制相當接近，但 Rust 往往需要使用大量不安全程式碼，而且 Rust 似乎缺少充足的原語組合來實現有益於開發者體驗的 JavaScript 程式碼移植目標。”
他解釋稱，團隊最終面臨著兩個選項。要麼使用 Rust 從頭開始重寫，而這可能需要耗費“數年時間”，並最終產生一個“沒人願意用”的 TypeScript 版本；要麼在一年之內用 Go 構建一個可用的移植版本，在語義方面“高度”相容，同時提供具有競爭力的效能表現。
Cavanaugh 同時強調，Go 與 Rust 一樣，都具備出色的程式碼生成、資料表示能力和“強大的”併發原語。就設計目標而言，Rust 的表現也算相當出色，但“將特定 JavaScript 程式碼庫直接移植為 Rust”則並不貼合這款程式語言的設計特性。
他承認，Go 其實也有類似的問題，但結合此前 TypeScript 的程式碼編寫方式，Go 出人意料地非常適合這項移植任務。
他在 GitHub 上的一篇帖子中補充道，“我們還有大量圖形處理任務，特別是涉及多型節點的向上與向下遍歷樹。Go 在處理這些工作時仍可提供良好的開發者體驗，特別是在處理 JavaScript 版本程式碼方面尤其突出。”
在接受採訪時，TypeScript 首席架構師 Anders Hejlsberg 也基本重申了 Cavanaugh 的觀點。
他提到，該專案的核心意義所在，就是要按原本移植現有程式碼庫。原始程式碼庫是根據某些假設條件設計而成——其中最重要的一點，就是必須存在自動垃圾收集機制。
Hejlsberg 表示，“可以說這限制了我們的選擇範圍，也讓 Rust 基本退出了決賽圈”，這裡指的當然是 Rust 缺少自動記憶體管理。
原始 TypeScript 與移植後的 Go 程式碼仍高度相似。
正如 Hejlsberg 的解釋，Rust 面對的另一個挑戰，是它對迴圈資料結構做出了嚴格限制，而 TypeScript 編譯器高度依賴迴圈資料結構。該系統包含具有父子引用的抽象語法樹（AST）、相互引用的符號與宣告，以及自然形成迴圈的遞迴型別。
“這些問題的存在，使得原生程式碼的遷移工作變得極其困難。”Hejlsberg 還解釋道，考慮到這種種需求，Go 最終脫穎而出、成為最合適的選項。
值得注意的是，TypeScript 建立在 JavaScript 之上。“如果大家經常使用 JavaScript，就知道向 Go 遷移比向 Rust 遷移要簡單得多。”
Hejlsberg 還表示，這樣的 Go 轉換對於系統的影響也非常溫和，畢竟其並不是那種強調繁文縟節的“特別複雜”的語言，“而 Rust 則恰恰相反”。
微軟預計將在 2025 年年中推出具備命令列型別檢查功能的原生 tsc 預覽版（tsc 即 TypeScript 編譯器）。到 2025 年底，專案構建和語言服務的完整實現版本有望釋出。目前最新的 TypeScript 版本是 TypeScript 5.8，TypeScript 5.9 也即將釋出。JS 版本的程式碼庫仍將持續開發，進入 6.x 版本系列。同時，TypeScript 6.0 將引入部分廢棄特性和破壞性變更，以便與即將推出的原生程式碼庫保持一致，Hejlsberg 透露。
“當原生程式碼庫與當前 TypeScript 版本達到足夠的功能對等時，我們將正式釋出 TypeScript 7.0。”
此外，Hejlsberg 進一步解釋道：“為了便於區分，我們會直接將它們稱為 TypeScript 6（JS 版本）和 TypeScript 7（原生版本），這一命名方式將在可預見的未來保持不變。
在內部討論或程式碼註釋中，你可能還會看到 ‘Strada’（TypeScript 的原始代號）和 ‘Corsa’（此次原生遷移的代號）這兩個名稱。”
與此同時，除了速度提升，原生版本還帶來了額外的優勢，包括：即時、全面的錯誤列表，覆蓋整個專案；更高階的重構能力；更深入的程式碼分析，此前由於計算成本過高而難以實現；同時為下一代 AI 賦能開發工具奠定基礎。微軟還計劃遷移至 Language Server Protocol（LSP），以更好地對齊其他程式語言的開發體驗。
“TypeScript 的核心價值主張是提供卓越的開發體驗。” Hejlsberg 寫道，“隨著程式碼庫規模的增長，TypeScript 的價值也在提升。但在許多情況下，它仍難以擴充套件到超大規模程式碼庫。”
參考連結：
https://devblogs.microsoft.com/typescript/typescript-native-port/
https://github.com/microsoft/typescript-go/discussions/411
https://thenewstack.io/go-power-microsofts-bold-bet-on-faster-typescript-tools/
宣告：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。
今日好文推薦