async-std 创建者对于最近“项目是否已死？”，移除对其支持等的答复

Rust 生态中，不谈官方的 Future trait，成熟可供生产环境使用的异步运行时，主要有三类：

• tokio。生态最为强大，是生产中使用最多的运行时。它具有高性能、可定制且灵活的执行器。不管从哪一方面说，都是 Rust 生态中最值得信赖的一部运行时。
• smol 和 async-std，实质是近乎一个团队的贡献。起初 stjepang 启动了 smol-rs 项目，目标是使 async-std 灵活的内部设计，可以供其它运行时重用。后来，async-std 的基础核心，也是基于 smol 的；而 smol 的则直接用到了 async-std 团队创建的 surf、tide 等。
• glommio。基于 thread-per-core 哲学并使用 io_uring 实现的专用运行时。与 Tokio 和 async-std 不同，Glommio 不是通用的异步运行时，也不包含诸如AsyncReadtrait 之类的东西。但对于它的应用场景，它是一个完整的解决方案。目前，web 开发方面，笔者了解到支持 glommio 运行时的，有 actix-web 创建者的新项目 ntex。

另外，还有专为嵌入式开发设计的运行时 embassy，以及 bastion 等等。

笔者喜欢 async-std 的 API 设计，所以手头的 Rust Web 方面的项目，也主要是采用 async-std，以及基于其的 web 框架 tide。这两个 crate，均很久没有实质有用的更新了。

最近，reddit 前后出现了 2 个帖子，一个是 async-std 是二等公民吗？；一个则更直接 sqlx 考虑移除其对 async-std 的支持，并发出灵魂拷问 “who would use async-std?!”；后续，github 中还有多个知名 crate 也提出此类放弃支持的讨论。因此，笔者也对其给予了很多的关注，将 async-std 自从 6 个月前版本发布后的提交历史，逐一看了一遍。

终于，在 2022 年 2 月 11 日，yoshuawuyts 在一个名为 和 tokio 比较（Tokio comparison） 的 issue 中，对一位用户的发言 “And what might be even more important - is the project dead?”，做了还算详细的回复。大约是以下几个意思——

• 不会死，目前正在探索如何创建一个对可维护性进行优化的实现，以及如何公开平衡易学性和高性能。而不仅仅是一个流行的运行时…… :-D 详细请点击上面链接了解哈，因为有些说法翻译尴尬，其它运行时可能不认同。
• 理解用户为什么有此担忧。
• smol 在 1 月份做了一次更新，所以虽然进度缓慢，但一直在推动。
• 不信任 stjepang 的工作（I don’t believe Stjepan works in Rust at all …），其不再是 async-std 核心团队的一员。
• 工作没有停止，但因为资金不足，所以集中的方向比较窄。
• 做的不够好的地方是社区回应很少等。
• tokio 相比 async-std 来说，使用它肯定不会收到任何指责（说话的艺术啊！ :-D）

这些回应虽然并没有解决提出 issue 和 pr 的开发者心中的担忧，因为 issue 和 pr 还是没人理；tide 仍旧是 issue 都基本没人提了，pr 堆积近百。

但是，对于喜欢 async-std 和 tide 的开发者和用户，至少保留了一份期待吧 :-)

附文中提到的 url：

• Is async-std a second class citizen?: https://www.reddit.com/r/rust/comments/l1rnn6/is_asyncstd_a_second_class_citizen/
• SQLX Proposal: remove runtime features and async-std support. Still using async-std? Please make yourself heard! - https://www.reddit.com/r/rust/comments/sjcf6r/sqlx_proposal_remove_runtime_features_and/
• Tokio comparison（async-std 社区，其中有 yoshuawuyts 的回复）: https://github.com/async-rs/async-std/issues/992