Meta/Facebook产品安全团队将调度服务从Python迁移到Rust？

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。