@
TypeError 引的文章有一些事实错误。因为误导比较严重所以单独说。
这篇文章和引用的其它一些链接没有分析清楚问题这个的来源，所以还有些（至少本应是）显而易见的错误。
虽然异步编程支持这方面上确实有 specific to Rust 的特别欠揍的地方，但是所谓 function 的 colour，根本上其实来自 async 。
文章认为 async/await 是一种相对于 Scheme 式的 CPS 抽象的进步，然而这是胡扯。Scheme 提供的是 first-class continuation，就是为了允许避免显式的 CPS 而能实现类似 CPS 的效果。
所谓 smear it out into a bunch of closures 在这样的支持 first-class continuation 的情形下就是一种实现细节。
想要异步代码干净，各种不同语言的设计思路都是允许用户写 direct style 的代码，然后让语言的实现自动翻译成 CPS 或者其它形式的显式异步表示形式。
这种变换，即便照顾同步 /异步的混用，逻辑上本来只要求 call site 区分所谓的 await，不需要关心是否 async 。需要区分不同的可调用实体是不是 async 的，反而把实现细节给暴露出来了。
要求用 asnyc 标注异步代码的主要原因是不愿意让运行时承担隐藏实现细节的责任，而改为强加到代码生成的机制上的偷懒，乃至于不惜牺牲接口上的一致抽象（所以有所谓的 colour 问题）。
这和滥用类型系统类似，经常就是一种过度优化（虽然影响的实现远比类型检查更麻烦）。Rust 本来就很有滥用类型系统的嫌疑，这里更容易打架毫不出乎意料。
至于 future/promise，是一种限制性的备胎而非 first-class continuation 或同等抽象能力的基础设施的替代。在语言没有能力提供健全的特性时，实现可以使用非公开的机制提供有限的 API 适用受限的场合。这可能提升特定有限场景下原语的实现质量，但也限制了通用性。