[Rust] 为 Async Rust 构建共享的愿景文档—— Rust 社区的讲“故事”，可获奖
💥 内容涉及著作权，均归属作者本人。若非作者注明，默认欢迎转载：请注明出处，及相关链接。
Summary: 2021 年 3 月 18 日，Niko Matsakis 代表 Rust 社区的 Async 基础工作组发表了一个倡议书：倡议 Rust 社区共同参与，为 Async Rust 构建一个共享的愿景文档。参与者可以基于自己真实的异步开发经验，提出建议；分享自己在异步开发中，遇到的困难和解决方法；分享自己在异步开发中，为了提高效率而采用的变通方法和技巧；甚至就是基于真实的异步开发经验，切合实际地描述 Async Rust 的美好未来……直至 2021 年 4 月 2 日，都是收集这些关于 Async Rust 现状的“故事”。随后，Async 基础工作组会进行头脑风暴会议，对这些关于 Async Rust 现状的“故事”进行审阅。头脑风暴会议结束后，Async 基础工作组将评选出“最幽默的故事”或“必须支持的贡献者”等奖项，以及获奖者。
Topics: rust rust-官方博客 async 异步
目前 Rust 生态中，异步开发方面，Rust 团队提出了基础规范。具体的 crate 实现，交给了社区。异步 crate 众多，应用较广的有 tokio 和 async-std 运行时。虽然没有分裂的实际，但社区中一直有担忧的声音。
2021 年 3 月 18 日，Niko Matsakis 代表 Rust 社区的 Async 基础工作组发表了一个倡议书：倡议 Rust 社区共同参与，为 Async Rust 构建一个共享的愿景文档。
- 参与者可以基于自己真实的异步开发经验，提出建议；
- 分享自己在异步开发中，遇到的困难和解决方法；
- 分享自己在异步开发中，为了提高效率而采用的变通方法和技巧；
- 甚至仅是基于真实的异步开发经验，切合实际地描述 Async Rust 的美好未来；
- ……
直至 2021 年 4 月 2 日，都是收集这些关于 Async Rust 现状的“故事”。
随后，Async 基础工作组会进行头脑风暴会议，对这些关于 Async Rust 现状的“故事”进行审阅。头脑风暴会议结束后，Async 基础工作组将评选出“最幽默的故事”或“必须支持的贡献者”等奖项，以及获奖者。
以下为 Niko Matsakis 的倡议书原文翻译（笔者水平有限，不适之处请予指正，联系方式见上图微信或页底邮箱）：
Async 基础工作组认为：在构建分布式系统方面，Rust 可以成为最流行的选择之一，从嵌入式设备到基础云服务。不管用 Rust 做什么，我们希望所有的开发人员都喜欢使用 Async Rust。为了实现这一点，我们需要将 Async Rust 从当前的 “MVP” 状态转移到每个人都可以使用的状态。
我们正在发起一项协作工作，为 Async Rust 构建一个共享的愿景文档。我们的目标是让整个社区参与到一个集体的愿景活动中：我们如何才能让使用 Async I/O 的体验不仅成为一个实用的选择，而且是一个 愉悦 的选择？
愿景文档，以应用现状作为出发点……
“愿景文档”以一组角色开始。每个角色都与其使用 Rust 的特定背景（例如：性能、生产率等）相关联；角色的背景，将影响其使用 Rust 时的期望。
让我给你介绍一个人，Grace。作为一名经验丰富的 C 开发人员，Grace 精通于高性能和高操控，但她有了个新的想法：希望使用 Rust 来获得内存安全。以下就是她的传记：
多年以来，Grace 一直在和 C/C++ 作斗争。她习惯于破解大量的底层技术细节，她的代码，可获得最高的性能。她在 C 语言导致的内存错误方面，经历过“史诗般”的调试。她对 Rust 很感兴趣：她希望保持 C 语言中的操控和性能，同时保证内存安全，以获得生产力上的优势。目前，她正在试验将 Rust 引入到她所研究的一些系统中，她还考虑在一些未来的项目中使用 Rust。
对于每个角色，我们都将写一系列的“现状”故事，描述他们在努力实现目标时，所面临的挑战（通常以戏剧性的方式失败！——译者注：太幽默了）。这些故事不是虚构的。这些故事融合了 Async Rust 使用者的真实体验，正如通过访谈、博客，以及 tweets 向我们报告的那样。为了让您了解这个想法，我们举出两个例子：一个是 Grace 必须调试她编写的自定义 future，另一个是 Alan（一个来自于 GC’d 语言的程序员）遇到堆栈溢出而进行的调试过程。
写“现状”故事，有助于我们弥补认知偏差：从事 Async Rust 开发的各位开发者，通常都是 Async Rust 方面的专家。我们已经对提高效率所需的变通方法很熟悉，我们知道一些小技巧和窍门可以让你摆脱困境。这些故事既是资料文献，有助于我们衡量其对学习者的累积影响。这些故事为我们提供了需要优先处理的数据。
……然后，告诉我们如何改变
当然，愿景文档的最终目标不仅仅是告诉我们现在在何处，而是要告诉我们要去向哪里，以及我们将如何到达。一旦我们在现状故事上取得了良好的进展，下一步，将会开启头脑风暴会议“光明的未来”。
“美好的未来故事”，将讲述 2 到 3 年后异步世界的情景。通常情况下，到时将会重演与“现状”故事相同的场景，但结局会更美满。例如，也许 Grace 可以通过一个调试工具，诊断她所陷入的任务，并告诉她这些任务的阻塞原因，这样她就不必通过 grep 浏览日志了。也许，编译器可以警告 Alan，告诉他可能的堆栈溢出，或者（更好的方法）我们可以调整 select 的设计，从一开始就避免这个问题。我们的理想非常丰满：首先关注于用户体验；然后走出前进的步伐（如果必要的话，也许会调整目标）。
译者注：此处笔者调皮了下。原文直译为“理想是雄心勃勃的：首先关注于用户体验，然后找出改进的方法”。
涉及整个社区
异步愿景文档提供了一个论坛，Async Rust 社区可以在论坛为 Async Rust 用户规划一个良好的总体体验。Async Rust 是特意设计的，不具有“一刀切”的思维方式，我们将不会改变这个初衷。我们的目标是为端到端体验构建一个共同的愿景，同时，保持我们松散耦合的构建模式、面向探索的生态系统。
我们编写愿景文档的过程中，鼓励积极协作，以及“正和博弈”思维。开始于一个集思广益的阶段，在此期间，我们的目标是收集尽可能多的“现状”和“光明未来”的故事。这次头脑风暴会持续六周，直到四月底。前两周（直到 2021-04-02），我们只收集“现状”故事。之后，我们将收受“现状”和“光明未来”的故事，直到头脑风暴期结束。最后，为了结束头脑风暴阶段，我们将评选出“最幽默的故事”或“必须支持的贡献者”等奖项，以及获奖者。
一旦集思广益阶段结束，工作组领导者将会整合各个“现状故事”和“光明的未来”，形成一个连贯的草案。该草案将由社区和 Rust 团队审查，并根据反馈进行调整。
想帮忙吗？
如果您愿意帮助我们撰写愿景文档，我们将很乐意为您贡献经验和愿景！现在，我们专注于创造现状“故事”。我们正在寻找人来撰写 PRs，或在 issues（github 项目的问题列表）谈论他们的经验，或其它任何地方撰写愿景文档。如果您想开始分享，请查看现状故事模板——其包含打开 PR 所需的所有信息。或者，您可以查看如何提出愿景页面，该页面详细介绍了整个愿景文档的流程。
各位老师，想参与么？奖项还是很丰富的，以下是全部的奖励类别：
- 最幽默的故事
- 最具创意的故事
- 最受支持的——谁留下了最有帮助的评论？
- 最多产的——谁写的故事最多？
- 最出乎意料的是——哪一个现状故事（或光明的未来）让你大吃一惊？
- 最痛苦的“现状”故事
- 最雄心勃勃的“光明未来”故事
- 最常见的问题
并且，还有自定义奖项。如果你有其他奖项类别的想法，工作组也很高兴采纳。但有一条规则：奖励不能是消极的(例如，不能是“最不现实的”)，也不能是关于哪件事是“最好的”。因为，违反规则的奖项，会与头脑风暴精神背道而驰。
谢谢您的阅读！
原文链接：Building a shared vision for Async Rust