行吧，居然把锅甩到我这里来了。
这段时间很火的，或者说「突然间井喷式地出现在公众眼中」的命令行替代品大部分都是 Rust 写的，我自己已经用上的有以下这些：
- bat (cat)
- exa (ls)
- fd (find)
- Rust 官方文档中教学模式的 grep

这些命令行无一不体现了 Rust 的「 blazingly fast 」特点，也证明了 Rust 比较适合于做基础服务。

在懂的人里面，这无疑在「暗示」吹捧 Rust， 那么我说个「 Rust 大法好」完全没啥问题吧，我也不是在其他语言出现的地方吹捧 Rust。


----

回到 LLVM 的问题上，我觉得 Rust 选用 LLVM 是有理由的，LLVM 极大地降低了在语言初期阶段过多设计 LIR 层面的设计和优化，利用 LLVM 可以得到其极其方便的跨平台，跨框架的编译优点，我觉得这也是 Rust 能做得那么好的原因之一「把仅有的、有限的精力放在该关注的地方」。

目前来说 Rust 只分析到了 MIR 层面，最大的 feature 就是利用 miri 库来实现 NLL 的分析，这已经极大的改善 Rust 的编程体验了。当然了，我也不是开发组的成员，但是我认为到了 MIR 都不能满足 Rust 的时候，再重新考虑制作一个 MIR2LIR 的库又怎样呢。

----
再回到 LLVM 的 coroutine 问题，Rust 从一开始标准库中带有异步库，到后来的移除，再到后来的「由社区自行设计的决定」，再到现在的「 async / await 语法糖引入」都是慎重选择的。当然了，也并没有说 到底谁的设计更好，只能说各自面向的群体不一样，导致取舍不一样把。

----

不好意思，我没听说过「完全自举」这个说法，能用 Rust 写出 Rust 编译器，然后用 这个新的编译器成功编译出新的 Rust，那么就是自举了。