初创公司使用 Rust 的感悟

共 3130字，需浏览 7分钟

· 2021-10-20

Rust

在建立一家公司时，你需要着手从根本上解决问题。出于这个原因，开发者们被这种改变世界的浪漫想法吸引了。我们本质上是问题解决者。

作为工程师，我们有时会（并且我们大多数人已经）对我们这些问题的解决方案充满热情。我们中有实用主义者，他们只是把事情做好——他们快速有效地解决问题。我们中有理想主义者，他们会努力寻找优雅的可扩展解决方案并尝试解决问题。无论你属于哪个阵营，在某个时刻，你都需要对将使用哪些技术来解决你在世界上看到的问题形成意见——而这种意见将不可避免地引起争论。

传统智慧是“为工作使用正确的工具”。例如，编程语言的选择取决于你要解决的问题的领域。如果你在一个隐蔽的项目中实施某种算法，很容易说明该工作的语言可能是什么。你可以运行基准测试并一一测试每种候选语言的执行时间（如果你正在优化执行时间）。你可以说服自己做出了一个理性和“客观正确”的决定。

然而，在刚开始开发业务时，你的优化功能是一个高维度的混乱，涉及性能、开发速度、招聘、服务器成本、生态系统、工具、支持、许可证等。你可以为对最重要的东西分配权重。但归根结底，业务起决定作用。

在 Synth，我们致力于构建世界上最好的数据生成器。我们有意识地决定将 Rust 用于我们的主要产品线。经过一年多的建设，我有机会在公司刚启动的背景下看到 Rust 最好和最坏的一面——这篇文章是这些（有时是愤世嫉俗的）想法的汇集。

开发速度

Rust 有着非常陡峭的学习曲线。来自 OO 背景的我花了几个月的时间才在 Rust 中有一定生产力。这挺让人失望的，因为我觉得我缺乏影响团队的生产力，确实是这样。即使你最终变得有生产力（而且你会），Rust 也会迫使你真正深入思考你正在做的事情，而事情不可避免地需要更长的时间才能完成。今天一个深思熟虑的设计决定可能会在几个月后再次困扰你。当你试图对借用检查器让步时，简单的更改或重构可能导致完全重来，这挺致命的。

初创公司整个的前提是你必须快速迭代。很少有公司从一开始就知道他们应该构建什么。这是一个迭代过程，涉及与用户交谈并进行更改来建立反馈循环。你建立反馈循环的速度越快，成功的可能性就越大。

正确性

Rust 强调程序的正确性，这在一定程度上弥补了开发速度的影响。可以这么说：“如果它可以编译，它就可以工作”。在使用 Rust 构建时，我发现这在很大程度上是正确的，因此用它工作是一种绝对的乐趣。

即使你的程序并不完美，你也能容易的了解故障模式。当你的程序完全按照你期望的方式中断时，未知故障模式的集合会大大减少。缺少空指针与 Result 范式（相对于异常）会让你编写正确的程序，其中边缘情况可以很好地理解并处理（或者 unimplemented!，但没有什么是完美的）。

如果你已经达到产品市场契合度 —— 正确性可能会抵消开发速度的影响。当你知道正在构建什么时，你需要减少迭代。你的开发团队也将花费更少的时间来处理错误，因为你在开发时，编译器已经处理过这些问题。

如果它可以编译，它就可以工作——当你积极地发布代码时，这是一个无价的资产。

人才

对于处于早期阶段的初创公司来说，获得优秀的人才是非常重要的。有能力和有经验的 Rust 开发人员的数量少，这一事实不利于获得优秀人才。Rust 陡峭的学习曲线加剧了这种情况，因为你需要有经验的人，否则他们需要几个月的时间才能开始开发。然而，这并不是全貌。

根据我们的经验，普通 Rust 开发人员的能力远高于更传统的编程语言。有些优秀工程师会因为你使用 Rust 而寻找你作为雇主，这也是一个惊喜。他们不想用 *script、Java 或 C++ 工作。他们想使用 Rust，因为它很棒。

开源

在 Synth，我们选择采用开放核心业务模式。开放核心业务背后的理念是你开发和开源产品，并获得许可，解决真正的技术问题。你致力于公开建立用户群、社区和出色的产品。然后，围绕解决相应的组织问题来构建业务模型——这就是你赚钱的方式。

我们真的很幸运有一群非常活跃的贡献者——提出想法、报告错误和贡献（有时非常重要）代码。很难确定，但我们有一种强烈的预感，很多贡献者都很活跃，因为他们对 Rust 项目特别感兴趣。我们的许多贡献者也对学习 Rust 感兴趣——不一定是该语言的老手。随着我们核心团队中更有经验的成员指导和审查年轻 rustaceans 的代码，建立了一个共生的正反馈循环，这非常有效。

感谢我们所有的贡献者——你们知道自己是谁，你们太棒了。

库

Rust 拥有令人难以置信的高质量库的生态系统。Rust 核心团队以身作则，专注于高质量和严密的标准库。高度集中的标准库的结果是（不幸的是）缺乏用于在标准库之外做事的规范库。所以你想要一个网络服务器，从可用的 100 个中选择一个。你想要一个用于处理 JWT 令牌的 crate（ Rust 库的术语）？有 9 个，选一个。我的意思是，即使是像异步运行时这样基本的东西也会在 tokio 和 async-std 以及其他选择之间区分。作为一个年轻的 rustacean，这可能有点不知所措。

随着时间的推移，最终，获得压倒性的支持并成为与其替代品不同的严重依赖项的那些库会变成隐式规范。同样在 RustConf 2021 的项目更新中提到^[1]，将来可能会有 “推荐 crates” 的想法。

在你开始时，缺乏规范的非标准库是一个问题 —— 但随着对生态系统的更好理解，随着时间的推移，这种情况会减少。什么一直在不断影响我们的发展速度，是一直缺乏的client Rust 库。我们不得不自己编写一堆不同的集成，但它们通常很笨重，因为我们没有时间使它们真正高质量。例如，谷歌的大部分产品充其量都有一个由社区维护的非官方代码生成的 crate，最糟糕的是绝对没有。你需要从头开始编写它。