Async 基础工作组 认为 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 用于一些全新的项目（greenfield projects）以及。

对于每个角色，我们将编写一系列 “现状”故事，描述了他们在努力实现目标时面临的挑战（通常会以戏剧性的方式失败！）这些故事并非虚构。 它们融合了使用 Async Rust 的人们的真实经历，这些经历通过访谈、博客文章和推文报告给我们。为了让您有个概念，我们目前有两个例子：一个是 Grace 必须调试她自己编写的自定义 future，另一个是 Alan —— 一个来自有垃圾回收语言的程序员 —— 遇到堆栈溢出并必须调试其原因。

编写“现状”故事有助于弥补 知识的诅咒：从事 Async Rust 工作的人往往是 Async Rust 的专家。我们已经习惯了 变通方案 以提高生产力，并且我们知道那些能让你摆脱困境的小技巧。这些故事帮助我们衡量所有小问题（paper cuts）对仍在学习的人可能产生的累积影响。这为我们提供了确定优先级的所需数据。

...然后讲述我们将如何改变它

当然，愿景文档的最终目标不仅仅是告诉我们现在所处的位置，更是告诉我们未来的方向以及如何到达那里。一旦我们在现状故事上取得良好进展，下一步将开始集思广益关于 “闪亮未来” 的故事。

闪亮未来故事讲述了未来两三年后 async 世界可能的样子。通常，它们会重演“现状”故事中的同一场景，但结局更加愉快。例如，也许 Grace 可以使用一个调试工具，能够诊断她卡住的任务，并告诉她这些任务阻塞在哪种 future 上，这样她就不必翻遍日志了。也许编译器可以警告 Alan 可能发生的堆栈溢出，或者（更好的情况是）我们可以调整 select 的设计以首先避免这个问题。我们的想法是雄心勃勃，首先关注我们希望创造的用户体验；我们会沿途找出实现的步骤（如果需要，可能会调整目标）。

吸引整个社区参与

Async 愿景文档提供了一个论坛，Async Rust 社区可以在此规划为 Async Rust 用户提供出色的整体体验。设计 Async Rust 时有意避免了“一刀切”的思维模式，我们也不想改变这一点。我们的目标是为端到端体验建立共享愿景，同时保留我们已经构建的松散耦合、探索导向的生态系统。

我们用于编写愿景文档的过程鼓励积极协作和“正和博弈”思维。它始于一个头脑风暴期，在此期间，我们旨在收集尽可能多的“现状”和“闪亮未来”故事。这个头脑风暴期持续六周，直到四月底。在前两周（直到 2021 年 4 月 2 日），我们只收集“现状”故事。之后，我们将同时接受“现状”和“闪亮未来”故事，直到头脑风暴期结束。最后，为了结束头脑风暴期，我们将评选出 奖项，例如“最幽默故事”或“最支持贡献者”。

头脑风暴期结束后，工作组负责人将开始着手将各种故事和闪亮未来整合成一份连贯的草稿。这份草稿将由社区和 Rust 团队进行审查，并根据反馈进行调整。

想帮忙吗？

如果您想帮助我们编写愿景文档，我们非常欢迎您贡献您的经验和愿景！目前，我们专注于创建现状故事。我们正在寻找愿意提交 PR（Pull Request） 或在 issue 或其他地方分享他们经验的人。如果您想开始，请查看 现状故事模板 —— 其中包含了提交 PR 所需的所有信息。或者，您可以查看 如何参与愿景文档编写 页面，该页面详细介绍了整个愿景文档编写过程。