我以前真的沒有想過 tsc 是用什麼寫的，反正存檔後紅線會出來就好。直到某次開一個比較大的 workspace，跳到定義要等、改完共用型別又整片轉圈，我才突然理解：編譯器本身用什麼語言、怎麼吃記憶體，原來不是維護者才需要在意的冷知識。
TypeScript 專案變大之後，型別檢查和編輯器提示有時會開始變慢。微軟在 2025 年宣布，要用 Go 重新打造 TypeScript 的編譯器和語言工具，希望縮短這些等待時間。
這裡的「原生」不是讓 TypeScript 直接在瀏覽器裡執行，而是把原本以 TypeScript 寫成的工具改用能編譯成原生程式的 Go。對一般開發者來說，最直接的感受可能是執行 tsc 更快、大型專案開啟後比較快出現提示。
重寫工具並不代表 TypeScript 語法要全部換掉。官方的方向仍是盡量保持相容，讓大家的注意力放在速度改善，而不是再學一套語言。
為什麼不是繼續最佳化原本的版本？
TypeScript 編譯器本身也是用 TypeScript 寫的，這對維護和貢獻很友善，但大型程式的型別分析會吃掉不少 CPU 和記憶體。原生程式可以更直接地使用多核心與管理記憶體，改善空間比較大。
Go 也不是因為它在排行榜上比較熱門。官方看中的是容易產生跨平台執行檔、平行處理成熟，而且程式結構能和原本的 compiler 保持接近。比起改用一套完全不同思路的語言，移植時比較容易核對行為。
當然，「官方展示快十倍」不等於每個專案都會快十倍。小專案原本只等一秒，差距可能沒那麼有感；真正受益的會是大型 monorepo、CI 型別檢查，以及編輯器需要反覆分析專案的情況。這篇比較適合談它為什麼值得重寫，不必替官方重做效能報告。
我比較期待的其實是那些很難截圖的改善。大型專案切換 branch 後，語言服務能不能快一點恢復；改動共用型別時，其他 package 的紅線能不能早點出現；CI 是否不用再把 typecheck 拆成一堆特例。每次只少等幾秒，累積在一天裡可能比一次漂亮的 benchmark 更有感。
另一方面，編譯器重寫最怕的是「差不多相容」。型別系統有大量邊界案例，某個原本能過的 generic 突然報錯，對使用者就是 migration 成本。因此我會把原生版看成一個需要生態一起完成的工程：compiler 快只是第一關，編輯器、eslint、framework plugin 和 declaration 工具都跟上，才算真的換完。