在 9 月 27 日直播的【开源漫谈】第 14 期节目中，开源中国 OSChina 邀请到了马全一、冯洋以及张汉东三位 Rust 专家就“快十年了，Rust 怎么还没有取代 C++”这一话题展开讨论。
直播期间，有网友指出，使用 Rust 编译生成的二进制文件，在端侧设备（比如嵌入式设备、物联网设备等）上比使用 C++ 编译生成的二进制文件要大很多。这在那些内存和存储空间资源受限的端侧设备上尤其需要注意。
对于这一问题，三位 Rust 专家给出了自己的看法。
冯洋：关于端侧设备上 Rust 编译文件大小的问题，我的理解如下。
首先，我们要弄清楚为什么 Rust 编译后的二进制文件会比较大。
目前，有多组人员正在努力解决这个问题，至少有三伙人在进行相关工作。
我个人也尝试分析过 Rust 的二进制文件，发现除了可以移除的调试信息和头部数据之外，其他部分很难进一步压缩。
特别是链接（linkage）相关的部分，如果不改变现有的编译系统，这些是无法删除的。
接下来，关于资源消耗的问题，我们可以将其分为计算资源和空间资源两个方面。
对于空间资源，我之前已经解释过，很难进一步减小文件大小，这需要 Rust 社区共同努力来解决链接问题。
至于时间资源，即运行时的内存消耗和计算成本，Rust 与 C 和 C++ 相比，表现大致相当，甚至在某些情况下，Rust 可能表现得更好一些。
张汉东：就像冯老师之前提到的，Rust 有些方面已经无法进一步优化，但情况并没有网友说的那么严重。
我在参与华为的一个项目时，也是在进行端侧的改造，将 C 语言的遗留系统转换为 Rust。转换后，与 C 语言相比，Rust 的二进制文件确实会大一些，大概多出几十 K。这部分增加是有优化空间的，我们知道使用 Rust 的宏会生成额外的代码，使用了泛型等特性也会增加文件大小。
如果经过优化，Rust 的二进制文件仍然会比 C 的大出十几 K，这是无法避免的，但在可控范围内。
除非是在资源非常受限的情况下，比如存储容量特别小，我们可以将核心库剥离出去，这样链接后的核心库大小可能只有几 K。如果剥离核心库，可能需要自己实现一些基本功能，如复制等。
这是最极端的情况，而现在这样的情况并不多见。通常情况下，使用 no_std 模式加上一些优化技巧，可以将 Rust 编译后的文件大小控制在一个可接受的范围内。
Rust 的编译大小、编译性能和编译时间之间需要平衡。如果追求性能，可能会牺牲编译时间和编译大小。
因此，需要根据实际情况来平衡这些因素。
马全一：Rust 社区的性质和编译文件大小在一定程度上影响了其在端侧设备上的适用空间。但从我从事社区生态工作的角度来看，我相信 Rust 社区自身的机制能够逐渐解决这些问题，虽然这不会一蹴而就。
Rust 社区相对来说是一个比较松散的组织。它的特性改进和发展方式，并不像有些项目那样由一个技术委员会来制定草案和分工执行。
在 Rust 社区中，如果你想要做一件事情，你需要自己投入精力，并影响周围的人一起参与。
因此，Rust 社区一直是自治型的，像个轮子式一样向前发展。
此外，还成立了 Rust 基金会。华为作为创始会员和白金会员，每年都会向基金会投入大量资金。我们会向基金会提出，例如编译文件大小这样的问题，因为它影响了华为使用 Rust 的场景，比如我们希望 Rust 能够应用于资源受限的交换机、路由器等设备。
我们希望整个社区能够推动这一进程。基金会会根据需求立项，并可能雇佣全职员工来推动某些事情，比如我知道最近基金会雇佣了一些负责安全的工程师来处理供应链安全的问题，以防止有人在项目中植入恶意代码。他们做了很多这样的工作。
所以，Rust 还有企业代表组成的基金会这样一个轮子在转动。Rust 社区实际上代表了两组人，他们目前正处于一个磨合的阶段。
去年，Rust 社区出现了一些不和谐的新闻，这反映出原本的社区自治模式在发展过程中遇到了挑战。
大公司如 AWS、微软、谷歌等加入后，他们希望影响 Rust 的演进方向，与社区之间正在进行磨合。
华为等公司需要有人在社区中发挥影响力，而谷歌等公司也希望在社区中投入资源，共同推动各个团队的合作。
要解决编译文件大小的问题，正如冯洋老师所说，需要整个编译器团队及其周边团队共同努力，而不是仅仅在现有的条件下进行优化。如果想要进一步减小文件大小，就需要整个团队的协作。
我和朋友聊天时，对方提到他们以前使用 Go 语言，在 Go 语言社区中提出 PR 并被接受的几率较低。
相比之下，Rust 社区会充分讨论并推动 PR 的进展，这让开发者更有信心使用 Rust。
因为如果遇到问题，他们有能力自己进行修改。这也是为什么有些公司愿意在核心问题上选择 Rust，因为 Rust 社区是开放治理的，不受单一或少数公司控制。
还有一点，我与同事讨论过如何在社区中推动事情的发展。如果你发现问题，应该想办法改进并提出方案，与社区一起解决问题，而不是仅仅提出问题后就不了了之。这不是社区应有的运作方式。
参与 Rust 社区的人们可能是因为他们有机会参与到语言编译器的改进工作中，这是使用其他语言时可能无法得到的体验。
当然，对于 PHP 来说，你有机会参与到语言的发展中。
但是如果是像 Go 或 Java 这样的语言，它们主要受一两家公司的控制，那么想要真正参与到语言的开发中去，实际上会面临很多困难。
这是我想要解释的，即从一个从事社区工作的角度来看，Rust 社区提供了更多参与和影响语言发展的机会，这是与其他受公司控制的语言相比的一大优势。
↓长按识别二维码
观看直播回放
最后，附上今日份 Rust 梗图（感谢读者热心投稿）：
