性能數據與測試條件說明

根據Cloudflare公布的早期基準測試，tsrs在相同類型檢查工作數的配置下，速度比TypeScript 7.0快達8倍，記憶體使用量減少約70%。值得注意的是，即將發布的TypeScript 7.1 beta版本本身已透過部分源自tsrs的優化，比7.0版本快達2.5倍。

針對外界對不同移植版本性能聲明的質疑，Cloudflare強調此次基準測試是與TypeScript團隊合作確保在相同配置下進行比較，避免了因使用較大機器類型或不同選項導致的數據偏差。tsrs預設提供依賴機器類型的自適應配置，該配置會使用更多記憶體以換取更快的速度。

選擇Rust而非Go的技術動機：WebAssembly與邊緣運算

儘管TypeScript團隊已將編譯器從JavaScript移植至Go並帶來顯著性能提升，Cloudflare指出選擇Rust的關鍵原因在於WebAssembly（Wasm）支援。當將Go程式編譯為Wasm時，必須同時編譯Go的垃圾回收器（GC），這增加了記憶體負擔；而Rust的記憶體管理模型允許Wasm客戶端與主機之間更直接的記憶體互動，無需額外GC開銷。

Cloudflare Workers長期支援Wasm，近期更宣布透過新的Emscripten目標支援原生Rust。這種低記憶體佔用的特性使得在Workers上以緊密循環運行整個軟體構建和部署系統成為可能，進而讓完全封閉的開發環境能夠在瀏覽器、嵌入式設備或IoT應用等以往無法運行的地方執行。

維護策略與上游協作機制

tsrs並非TypeScript的分叉，團隊強調TypeScript團隊應保留對語言設計和發展方向的完全控制權。為了避免移植版本因脫離上游決策而最終崩潰或不相容，tsrs必須嚴格遵循原始實作的決定。目前團隊正與Theo Browne合作，將tsc-rs和tsrs合併為單一套件，以支援包括語言伺服器協議（LSP）和内容映射器在內的所有TypeScript功能。

維護流程參照了Vinext專案的成功經驗：每個早晨由AI代理審查上游變更、獲取差異並開啟追蹤問題；每晚重新生成相容性矩陣，將Next.js測試套件針對Vinext運行。當發現差距時，代理可識別兩個代碼庫中的變更、建立重現步驟、移植相關測試並提出修復方案。此流程將應用於TypeScript，並承諾將發現的性能優化貢獻回TypeScript的Go代碼庫。

社群回饋與技術實現細節

TypeScript團隊成員Dan Rosenwasser表示，他們正在與tsrs維護者合作理解其速度優勢及安全優化手段。初步分析顯示，部分性能提升並非僅來自語言選擇，而是來自於特定的代碼優化策略，這些策略也被應用於讓TypeScript 7.1更快更精簡。

社群討論指出，tsrs採用了一種獨特的記憶體模型來克服將GC語言移植到無GC的Rust時的挑戰：透過為長期存在的物件使用永不釋放的記憶體區域（arenas）來模擬垃圾回收。另有觀點認為，開發tsrs的主要動機是為了在僅支援Wasm的沙箱中運行TypeScript編譯器，避免Go Wasm版本的完整執行時開銷，而性能提升是意外收穫。

AI輔助移植與未來整合計畫

Cloudflare指出，前沿AI模型現在能在數天內幾乎獨立完成大規模代碼移植，這使得過去因複雜性而失敗的多次嘗試成為可能。目前已有忠實移植版和完全重構架構的Rust或C++版本出現，顯示市場對更快TypeScript的需求。

Cloudflare計畫將tsrs更深入整合到其技術棧中，例如在Oxlint中實現類型感知的規則檢查。團隊目標是將tsrs作為一個維護良好的開源專案運行，同時不干擾TypeScript本身的發展。目前tsrs已可透過npm安裝實驗性版本（npm install tsrs），但存在與上游版本的行為差異，如診斷訊息列印順序，團隊承諾在穩定版發布前將這些差異降至最低。