Meta/Facebook產品安全團隊將排程服務從Python遷移到Rust？

 Facebook 產品安全團隊通過構建大規模模糊測試基礎設施和工具來進行動態分析。

其中有一個模糊排程程式服務，該服務是他們更廣泛系統的“大腦”：

它負責將工作分派給大量機器，並確保所有的模糊測試特定業務邏輯正常工作。

他們最近將此服務從 Python 遷移到 Rust。現在，將大約 30% 的時間花在 Rust 上，其餘時間花在 C++/Python/Hack 程式碼庫上，並希望它們也在 Rust 中！

這是他們為什麼選擇使用 Rust 而不是其他語言的原因：

我們的服務需要重寫，因為舊系統已經使用了 2 年多，並且無法擴充套件到我們需要構建的新用例。一旦我們同意需要重寫，我們面臨的第一個問題就是語言選擇。我們很快排除了 Python，因為我們現有的 Python 服務儘管投入大量資金對其進行優化，但仍面臨著重大的擴充套件挑戰。這讓 C++ 或 Rust 成為我們的選擇。鑑於並非團隊中的每個人都熟悉 C++ 的複雜性，有人擔心我們會在多執行緒服務中除錯棘手的記憶體損壞或競爭條件錯誤；而不是花時間為我們的使用者創造價值。

我已經將 Rust 用於一些個人專案和工作中的一些副專案，並希望以專業身份使用更多。在討論了編寫多執行緒非同步程式碼時的記憶體安全優勢、效能優勢和正確性保證之後；我們覺得 Rust 可以讓我們更快地釋出無錯誤程式碼。團隊的其他人也好奇地學習了一段時間 Rust，這個機會太好了，不能錯過！

在過去的幾年裡，我一直對 Rust 充滿熱情，而且軌跡看起來比以往任何時候都好。幾年前，當我們編寫初始排程程式服務時，我們實際上決定*反對* Rust，因為與 Facebook 內部庫和工具的整合不夠。現在已經建立了很多基礎，在 Rust 中建立一個服務並專注於你的業務邏輯而不是與缺少的庫整合真的很容易。而且，如果您仍然需要新增整合，cxx 之類的工具可以在幾個小時內輕鬆完成！當人們問我新程式碼的語言選擇時，我現在傾向於預設使用 Rust。

Facebook 貢獻了大量的庫和工具來簡化 Rust 的編寫。

我認為cxx是一個改變遊戲規則的人：我看到 Rust 採用的主要障礙之一是希望使用大量現有程式碼。使用cxx，即使對於複雜的庫，整合 Rust 和 C++ 程式碼也最多需要幾個小時，結果在兩種語言中都符合人體工程學，並且使用安全。我認為這將非常重要，因為人們希望逐步將程式碼遷移到 Rust，這是在更大的程式碼庫中將安全關鍵程式碼段遷移到 Rust 的好方法。我在每個可能的方向都使用了cxx（Rust 呼叫 C++、C++ 呼叫 Rust，以及 C++ 呼叫 Rust 並回撥到 C++ 的情況）。一切都很棒！

Facebook 還維護了一個通常有用的 crate 庫，並在我們所有的專案中使用。我們在我團隊的生產服務中使用了很多這些，最顯著的是滿足我們所有儲存需求的 sql crate。