Rust 的 2018新年计划

我希望 2018 年是无聊的一年。我不希望它变得缓慢，我希望有很多事情要做，但我希望这些工作是“无聊”的。

我们在 2017 年获得了许多新的东西，感觉像是令人兴奋的一年（新的语言功能、新的工具、新的库、全新的编程方式（！）、新书、新团队等等）。这真的很棒，也真的把 Rust 推向前进，但我觉得我们一路上累积了大量的技术和社交债务。

希望 2018 年能够成为对 2017 年的收获的巩固年，偿还技术债务，并将新事物打磨到伟大层面。更普通的情况下，我们可以想象到 Rust 的演变 - 2015 年和 2017 年是有很多大的、新事物的年份，2016 年和 2018 年应该是用来巩固的年份。

一些细节

以下内容不分先后顺序。

• 完成设计并且实现 ‘in flight’ 语言特性：

• 常量表达式

• 模块和箱子

• 宏

• 默认泛型

• 更符合人体工程学

• impl Trait

• 专业化

• 以及更多 ...

• 稳定债务（有很多特性其实已经完成了，但需要稳定。这是一个很大的工作量，因为这个阶段的风险比语言设计过程中的任何节点都要高。所以虽然看起来像是只要在方框中打钩，但实际要花很多时间和精力。

• 异步/等待 - 朝一个完全集成的语言特征和完整的库支持的方向努力，让 Rust 成为异步编程的首选。

• 安全指南 - 我们需要以此作为可靠、安全和方便的编译器的优化设计。现在有太多的不确定性。

• 支持 web assembly - 该工作已于 2017 年底开始，Rust 在该领域有很多机会。

• 编译性能 - 我们在2017年做了一些大的步骤（增量编译），但是在编写 Rust 程序之前有很多“小”的工作要做。 这也是一个伟大的 IDE 体验所需要的。

• 错误处理 - 错误库是一个好的开始，我认为这对于可靠性是非常重要的。还有其他非常重要的事情，比如：在主函数中稳定的 catch 块，还有很可能是更好的函数返回语法。

• IDE 支持 - 我们正在前进，并在 2017 年取得了好的进展。我们需要发布 RLS，改进编译器的集成，然后我们会有很多改进体验的机会，例如：调试器集成和重构工具。

• 其他成熟的工具 (Rustfmt 和 Clippy 都应该有 1.0 版本，我们应该有一个强大的发布机制)。

• Cargo

• 建立系统集成（我们计划在2017年完成，但还没有开始实施）

• 正在进行的 crates.io 改进（特别是我认为我们需要着手处理 crate squatting 问题 - 我们已经避开 curate crates.io（安全问题除外），我认为适度低调的调节和管理将大大改善生态系统）

• Xargo 集成

• rustup 集成 (请看下面)

• Rustdoc - 在 2017 年，有一些令人兴奋的工作，我认为我们可以做出一些大的改变，包括指导式的文本，智能源代码的探索，以及更便于使用的导航。

• 调试

• 为中级程序员提供学习资源 - 对于初学者 Rust 程序员来说，2017 年是非常棒的，在 2018 年里，我希望看到更多提供给中级程序员的文档、讲座等，这样，当你成长为 Rust 程序员时，不至于跌入无支持的深渊，特别是如果你不想积极参与 irc 或其他“直播”频道时。

• 团队结构 - 我们在 2017 年大大拓展了我们的团队结构，增加了一些新的团队和新的团队成员。我认为这一切都有所改善，但感觉总是有未完成的工作 - 有些团队仍然觉得他们正在起步，而另外一些则感觉过于宽泛。

• 润色 RFC 流程--RFC 流程是 Rust 强大的优势之一，在需要强大的提前设计的情况下确实有所帮助。然而，它也相当重量级，可能是一个巨大的时间陷阱，在某些场合下是压力和负面能量的真正来源。我认为我们需要重新平衡一些事情，虽然我不太确定如何做。

• 交流渠道 - 我们有很多交流渠道，但没有一个真的很棒 - 很多人不喜欢 irc ，这是一些人进入的障碍，很难调和。讨论论坛相当不错，但是不能很好地促进互动交流。GitHub（至少主 Rust 存储库）可能是非常庞大的，很容易错过重要的信息。我们在 impl 期间尝试了 Gitter ，我们用 Slack 来做一些小的事情。两者似乎都不错，有其自身的错误和问题，相比 irc 并没有提供太多功能，再加上这意味着更多的渠道需要密切关注。 r/rust 处于一个奇怪的半官方状态，有些人真的不喜欢 Reddit 。我不认为这里有一颗“银弹”（指某种新科技），但我认为我们可以改进和完善。

一些新东西

好吧，还有一些急需完成的新东西。我想尽量保持这个清单的简短：

• 新纪元 - 现在是时候做这些了。我们应该制定哪些东西不会再用了，并为新特性腾出时间来“适当”实现。

• 国际化（i18n） - 我认为尽可能多的人可以使用软件是非常重要的，且当这些实现的工具是集中化和官方化的情况下，软件的生态系统会做得更好。我们应该开发库和语言特性来帮助实现国际化和本地化程序。

• 集成 cargo/rustup - 没必要将这些作为单独的程序，会增加了新程序员的上手难度。虽然这是一个相对较小的事情，但我觉得它有很大的影响力。

• 测试 - Rust 内置的单元测试非常简洁，但我们也需要提供更强大的测试框架。

优先级

这许多很多的考量！而且我可能错过了一些库和社区的东西，因为我并不是真正了解那里正在发生的事情。我认为这差不多是一年的工作量了，但前提是我们能够抵抗住那些在此基础上更有魅力的、闪光的事情的诱惑。

我可能有些偏见，但工具（包括 Cargo ）似乎是一个需要做很多工作的领域，并且这些工作是很重要的。这也是一个感觉“人手不足”的领域，所以我们要么鼓励更多的人关注工具，要么削减我们想要实现的目标。

目标

在 2018 年年底之前，我希望 Rust 能够成为一个真正坚实的、可靠的编程语言选择。希望能形成拥有向后兼容性和稳定性的最优秀的声誉，而不是停滞不前。希望社区领导者感觉自己是一台运转良好的机器，让越多的社区参与者信任领导班子。希望在进行中的项目数量要少得多，未答复的问题要少得多（而且有更多的项目正在完成或达到成熟阶段）。希望“普通”用户能够感觉到我们在创新和稳定性之间所取得的平衡。

关于作者

Nick Cameron，是 Mozilla 的一名研究工程师，主要工作于 Rust 语言。

原文来自:开源中国社区

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com