考虑下在 readme 里面吧代码块加上 语言标志，不然没有代码高亮

还好吧，我遗传性发际线后退都几年了，已经完全习惯了。

resume 包成一个 zip，反正我是不敢下载的

国外 DNS 这两天一直不行，要把梯子关了才能正常打开

JINS 海淘

@jiangnanyanyu 现在我是一个 zhePython 的去写 java

这是编译原理 语法解析不及格的语法啊 明明可以复用 <@ @> 就够了，偏偏还要搞多一个 <@@ 。
不过这样的话就可以简单的用 regex 来替换就完事了

行吧，居然把锅甩到我这里来了。
这段时间很火的，或者说「突然间井喷式地出现在公众眼中」的命令行替代品大部分都是 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，那么就是自举了。

刚买旧款，哭晕

https://github.com/Kilerd/rubble 自己建的程序

@henglinli Rust 在 RFC 阶段已经有了自己的 async await 系统，而且目前已经快实现完成了。

基于 LLVM 是可以获得很多来自 LLVM 的优点和便捷，可以把更多的精力放在「如何设计一门好的语言」上

基本都是 rust 写的，Rust 大法好

守望先锋国家队在早上 9.50 以 3:0 的豪华战绩战胜芬兰队，晋级四强，取得历史最好战绩！
这才是我关心的

酿酒工艺，跟妹纸出去喝酒聊这聊那贼舒服

目前 block 在 GraphQL 的集成上，准备着手先做 RSS 和 Pagination 的 工作