我是 telegram 有一个 bot ， 你发送给他， 他就帮你转存到 github repo 。
people die ，but long live the github

楼上说得其实都不对，swift 也是基于 llvm 的，怎么没见 swift 编译慢呢？
在 rust 1.60 的更新里面 cargo 支持了一个 timing 的参数来导出编译时间分析 https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html#cargo---timings

业界普遍对 rust 编译慢的认识主要有几点。
1. 真泛型的 monomorphization (不知道怎么翻译这个)，倒是了拆解 generic 后的 code bloat 问题，代码技术一下子变得很大。
2. rust 自身几乎不做任何优化的产生 llir ，几乎所有的优化都基于 llvm 自己来做处理，这就是为什么同样基于 llvm 的 swift 不会有这样的问题。
3. rust 在产生 llir 之前经历了 HIR MIR LIR 的阶段，parse 分析等，尤其是 NLL 等特性加入导致其实对于 lifetime ，ownership 的分析会变得很重(具体可以看看 timing 的分析)，https://github.com/rust-lang/polonius 基于代数的新型分析器可能能解决这个问题。
4. 如果真是 llvm 的问题，你可以完全切到 cranelift 去试试编译看，其实提升也没有很大就是了。

https://transform.tools/json-to-rust-serde

来看看这个，你想要的都有

之前用 beancount 来记，但是自己有仓鼠症，喜欢收集小票，beancount 对 transaction 的文档支持不太好，所以就自己魔改 beancount 做了一套自己的记账软件。

游戏公司 早 10 晚 7 ， 我觉得绝大部分人都没那么天真的会相信吧。

无他,但手熟尔。
遥想当年，高中英语没怎么及格过，大学四级考了几次才能过。现在在外企混了几年，不一样跟老外同事谈笑风生？

入职腾讯之后，这个论坛就再也没有人安利 APIJSON 了。

lib 用 thiserror ，bin 用 anyhow

自己看 TRPL 估计都比这个好使。

[Imgur]( https://imgur.com/YHnTWtE)

19 年开始把自己的作品往 GitHub 上面放