< 返回我的博客

Mike Tang 发表于 2020-06-11 18:27

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 那套机制要深入理解透,理解透了,写起来其实也是挺爽的。对库层级来讲,基本就是可插拨的状态机扫描过程(试想国际空间站)。也是一种编程模式。将异步逻辑流程,转化成嵌套组合状态机扫描,本身也是一种成功且有趣的思想。

评论区

写评论
作者 Mike Tang 2020-06-12 21:44

这个很重要啊。想当于 async-std 想成为所有库的底层。而 smol 是在业务层想办法。as对已有同步库有强烈侵入性(以前的库改代码来适配as)。smol是适应已有库。

这么分析之下,async-std 的尝试其实算走到死胡同了。曾经想通过保持结构名和方法名保持一致来达到无缝切换的梦想破灭了。都怪这该死的 async 关键字。async-std 不可能消除这个具有传染性的 async 关键字。

886。

vkill 2020-06-12 18:29

可以直接使用这些 crates 散件进行 async 编程

这些 https://github.com/stjepang/piper/blob/master/README.md#piper-deprecated

1 共 2 条评论, 1 页