轉自21CTO
昨天我們已經報道，微軟已準備好將 TypeScript 編譯器和工具集移植到 Go，從而實現跨不同程式碼庫的 10 倍以上編譯速度。
儘管開發者普遍稱讚這項聲明，但仍有一些人表示了失望，因為微軟選擇了 Go 而不是 Rust 來移植 TypeScript 編譯器。
X平台上的一位用戶「完美「地總結了整體情緒。 「比 TypeScript 獲得 10 倍加速更令人震驚的是，但他們沒有用 Rust 編寫它，」他這樣說道。「
轉眼間，Java 與 C# 之爭就變成了 Rust 與 Go 之爭。特別感謝 TypeScript 讓這一切成為現實。」
另一位網友如此說道。隨著開發者不滿情緒的不斷湧現，TypeScript 的首席開發人員Ryan Cavanaugh澄清了這一立場，他們已經預料到，人們會就此展開爭論。他說，雖然 Rust 被認為是一種選擇，但「關鍵限制」是可移植性，這確保了新程式碼庫在演算法上與當前程式碼庫相似。
他也透露說，微軟TypeScript 團隊們探索了多種方法來表示程式碼，以便用 Rust 重寫程式碼。
但它們在性能和人體工學方面卻遭遇了「不可接受的」權衡，有些方法需要實現自己的垃圾收集器 (GC)，這增加了額外的複雜性。這與 Go 形成了鮮明對比，Go 會自動回收內存，也就是所謂的「垃圾收集」。
Cavanaugh 說：「其中一些已經很接近了，但通常需要插入大量不安全的程式碼，而且 Rust 中似乎沒有太多的原語組合可以實現 JavaScript 程式碼的人體工學移植。」 他解釋說，團隊最後有兩個選擇。
一是使用 Rust 從頭開始重寫，他說這可能需要“幾年時間”，而且仍然會產生一個“沒人能使用”的不相容 TypeScript 版本。二是在一年內用 Go 建造一個可用的端口，它在語義上「極其」相容，同時提供具有競爭力的性能。
Cavanugh 也表示，Go 與 Rust 一樣，具有出色的程式碼產生、資料表示能力和「優秀」的並發原語。
他還指出說，Rust 在實現其設計目標方面表現出色，但「從這個特定的 JavaScript 程式碼庫直接移植到 Rust」並不在其中，這很合理。
他解釋說，這同樣適用於 Go 語言，但考慮到他們迄今為止編寫程式碼的方式，它出乎意料地，非常適合這項任務。
「我們也進行了異常大量的圖形處理，特別是遍歷涉及多態節點的上下行走的樹。Go 在使這變得符合人體工學方面做得非常出色，特別是在需要模仿 JavaScript 版本的程式碼的情況下，」他在GitHub上的一篇文章中補充道。
“過渡到 Go 比過渡到 Rust 要簡單得多”
在一次媒體訪談中，TypeScript 首席架構師 Anders Hejlsberg很大程度上重申了 Cavanaugh 的言論。
他說，該專案唯一有意義的方式就是按原樣移植現有程式碼庫。原始程式碼庫的設計是基於某些假設，其中最重要的假設是存在自動垃圾收集。Hejlsberg 表示：“我認為這在很大程度上限制了我們的選擇，並開始嚴格排除 Rust”，這表明 Rust 缺乏自動記憶體管理.
Hejlsberg 指出，Rust 的另一個挑戰是它對循環資料結構的嚴格限制，而 TypeScript 編譯器嚴重依賴這種結構。該系統包括具有父引用和子引用的抽象語法樹 (AST)、相互引用的符號和聲明，以及自然形成循環的遞歸類型。「試圖解開所有這些問題將使遷移到本機程式碼的工作變得難以克服，」他說。 Hejlsberg 還解釋說，當他們考慮所有需求時，Go 脫穎而出，成為最合適的語言。值得注意的是，TypeScript 是建立在 JavaScript 之上的。 「如果你之前使用過 JavaScript，你會發現轉換到 Go 比轉換到 Rust 要簡單得多，」Hejlsberg 說。他也表示，此次過渡對系統的影響非常溫和，並不是需要大量儀式感的「超級複雜」語言。 「我認為 Rust 更接近後者，」Hejlsberg這樣補充道
