20200611

• smol 0.2 要分成三个 crates
• smol 现有的 api 接口可能会有一些变化。但是功能结构基本就这样了，后面会分得更明确。支持的平台更多。
• smol 目前对 windows 支持还不完善
• smol 未来会支持更多 event loop (或者也可以叫 runtime)，如 glib 的 event loop
• smol 会对 wasm 进行完美支持
• smol 的意义在于，可以将网络库由同步代码变为异步代码。而对库的代码没有要求。而 async-std 之类对库代码有侵入性，比如要求加 async 关键字。从而与 sync 代码形成两套，同步和异步要分开写。smol不存在这个问题。对于网络库，未来基于 smol，可构建更加统一的网络生态。写库的人在写的时候，基本不用管异步场景了。输出接口都是无 async 关键字的（async 关键字有传染性，严重警告！）
• smol 未来，有可能能在 no_std 下使用
• smol 可以说是在已有标准库的基础上，在同步的模式上，进行异步化的最小封装，最小化升级努力，干净！对比之下，async-std有点重，抽象的事情做得过多。当然也是有它的优点的。smol配合 futures-rs 本身的抽象，已经能基本解决绝大部分场景的问题了。async-std内部做了很多策略，默认约定。这个在 smol 里面非常少，因此 smol 就很让人放心。
• smol 最后会形成一批 crates，配合使用。因此，可以直接使用这些 crates 散件进行 async 编程。而 async-std 更像一个大一统的集成方案
• async-std 1.6 版本后，基于 smol 来重构了，也印证了我们上面的结论
• stjepang 大佬最近已经没给 async-std 贡献多少了。主要在弄这个 smol 库。他在19年12月在async-std官博上写完最后一篇blog后，就在他自己的博客上写了他自己的为什么要写一个新的runtime这篇文章。里面讲述了原因。他认为自己在 async-std 的工作并不完美，有很多妥协的不够好的策略。仔细理解看了后，能理解他说的
• 我们知道 async-std 能成的关键，其实也是 stjepang。不是说其它人不强，只是更喜欢 stjepang 思考和处理问题的方式。
• 同理，个人对 tide 的设计也不喜欢。个人品味问题。
• 另外，其实最原始的手撸 Future 那套机制要深入理解透，理解透了，写起来其实也是挺爽的。对库层级来讲，基本就是可插拨的状态机扫描过程（试想国际空间站）。也是一种编程模式。将异步逻辑流程，转化成嵌套组合状态机扫描，本身也是一种成功且有趣的思想。