其实我不是想讨论编译速度问题，尽管有点扰人，但它本身并不是个问题。我想指出的是一些一门成熟的编程语言不应该有的问题，而一门语言只有一个编译器就是其中的一个问题。
首先，自举过程非常糟糕。我知道这并不容易，但如果 Rust 被认为是一门系统编程语言，那么就应该能够通过几个步骤来自举编译器。例如，IIRC Guix 对 C 编译器的自举过程：用简单 C 编译器 (通常可以通过手动编写汇编代码实现) 编译 TCC，用 TCC 编译 GCC 2.95，用 GCC 2.95 编译 GCC 3.7，用 GCC 3.7 编译 GCC 4.9。对于 rustc 来说，你要么使用原始的编译器（使用 OCaml 开发的），然后使用前一个版本编译后一个版本 (即使用 1.16 编译 1.17)，要么使用 mrustc（使用 C++ 开发的），它可以编译 1.19 或 1.29(没有借用检查)，然后使用 1.29 编译 1.30，使用 1.30 编译 1.31，以此类推。这里的问题是，你不能跳过版本，比如用 rustc 1.36 编译 rustc 1.46。在我看来，你应该有一种编译器，效率可以不高，但要用一种老编译器能够理解的方言来开发，即使用 rustc 1.0 编译 1.10 的编译器，这个编译器可以用来编译 1.20，以此类推。当然，这是个理论问题，所以可能会浪费资源，但对编译器设计本身是有好处的。
接下来是 LLVM 依赖问题。我知道 LLVM 有很多优点 (比如不需要担心在多平台上的代码生成和优化问题)，但它也有一些缺点。首先，没有一个真正的自托管编译器 (这也是一个理论问题，但仍然值得我们思考）。其次，它的一些行为会限制我们。例如，我看到有很多人抱怨调试构建的速度太慢，主要是因为 LLVM 后端导致的。我猜想它仍然不能做一些与内存相关的优化，因为它的设计参考了 C++ 编译器，而后者仍然存在奇怪的多内存访问问题。我知道现在有 cranelift，所以希望这个问题可以得到改善。
最后，还有一个与上一个问题相关的问题。Rust 对汇编的支撑很差。当然，并不是所有人都需要汇编支持，但面向系统编程的语言除了支持高级语言代码外还应该要支持编译汇编，所以也应该支持汇编文件，即使不像 GAS 那样提供了丰富的预处理器语法。我们可以用 build.rs 来调用外部汇编器，但这样一点也不好。
