编译器是否有自托管的实际原因？

Question

如果您的引导语言编译器运行良好且可维护，为什么要更改它？例如，Go 在 1.5 版本中将其编译器重新编写为自托管，这导致 compile times to become much slower：当 Go 的目标是快速编译时，这是一个明显的不利因素。

Answer 1

一个实际的原因是社区。如果编译器是用同一种语言编写的，那么用你的语言编程的人可能更喜欢在编译器中编程。如果我的编译器是 Fortran/COBOL 并且它生成 Go 我不太可能将 Go 开发人员吸引到编译器。

另一个是构建链，即依赖项。如果您有一个用一种语言编写的编译器并生成另一种语言，那么当您可以满足于一套时，您就有两套测试要编写。这也降低了进入的门槛，即您不需要开发人员了解多个工具链等。了解两种语言足以成为一名称职的编译器编写者是一项艰苦的工作，并且会缩小您的潜在受众寻求帮助的范围。 获得帮助对于大多数开源项目来说都非常重要，任何能增加潜在开发人员基础的东西都是绝对的实际优势。

您还可以将测试列为额外的好处。如果您编写了一个自托管编译器，那么该语言需要做很多事情来使其相对容易（而不是拔牙）自托管，即文件 IO、字符串操作、符号表、树和列表等。显然，您没有所有这些也可以生存，但它开始使编写编译器变得更加困难。这种坐在吃你自己的狗粮营地。

它被认为是Rite of Passage，但我不认为这是一个非常实际的理由，除非你可以证明它吸引了开发人员或其他一些理由去做，也许对成就感觉良好是一个实际的好处，即你不太可能放弃它。

这里有一个有趣的话题...

https://softwareengineering.stackexchange.com/questions/263651/why-are-self-hosting-compilers-considered-a-rite-of-passage-for-new-languages

出于某些具体原因，请阅读 Rob Pikes 幻灯片，了解他们为何将 Go 编译器移至 Go instead of C。幻灯片中的结论是：

1. 摆脱 C 是该项目的一大进步。
2. 代码更简洁、可测试、可分析、更易于处理。
3. 新的统一工具链减少了代码大小，增加了可维护性。 灵活的工具链，便携性仍然至关重要。

根据语言的不同，您从中获得的好处可能会有所不同。