前端工具Rome將用Rust改寫

為什麼改用 Rust？
我們最關心的是我們自己的生產力。
最初很難想象一個由 JavaScript 開發人員組成的小團隊能夠在幾周內掌握足夠的專業知識來構建複雜的語言工具並提高工作效率。然而，經過一些原型設計之後，我們很快意識到我們實際上可能在 Rust 中更有效率。
Rome 早期的主要決定之一是不使用任何第三方依賴項——我們甚至用我們自己的封裝了 Node API。這個決定是基於嚴格控制 Rome 內部所有程式碼的願望，以便我們可以保證效能、記憶體使用和正確性/型別安全。
然而，其中許多問題在 Rust 及其社群中得到了解決：

1. 對第三方依賴的權衡更少 大多數 JavaScript/npm 包都必須平衡許多不同型別使用者的不同關注點。他們被迫圍繞我們不感興趣的程式碼大小和效能進行權衡。另一方面，Rust crate 通常會做出更接近我們需求的權衡。
2. 正確性內建於標準庫和大多數流行的 crate 中。 我們正在建立自己的 API，專注於正確性，而不是使用第三方 JavaScript 依賴項。Rust 及其社群更加關注正確性，而沒有為羅馬需要擔心的邊緣情況鋪平道路。
3. Trait/Module 系統允許我們更好地利用依賴關係 Rust 的 trait 系統是一種強大的方式，可以在沒有開銷的情況下建立對任何資料的抽象。它允許我們深度整合第三方庫。它還允許庫建立增量更多的 API，安全地暴露更多的表面積，而無需進行重大更改。

改變的地方
當我們開始在 Rust 中進行原型設計並重新審視我們的許多基本設計決策時，這也為我們提供了重新審視我們架構的機會。很快，我們意識到我們想要做出一些非常大的改變。
如果您曾經花時間學習編譯器的工作原理，那麼您可能聽說過以下內容：

1. 原始碼→詞法分析→標記
2. 標記→句法分析→抽象語法樹
3. 抽象語法樹→各種變換→一些中間表示
4. 一些中間表示→程式碼生成→ { Machine,Byte,Source} 程式碼

• 在開發人員進行程式碼更改時增量構建專案。
• 在編譯器完成工作之前請求有關某些程式碼的資訊。
• 即使程式碼包含語法錯誤，也要繼續提供反饋。