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

Question

如果引导语言中的编译器运行良好且可维护，为什么要更改它？举例来说，重新编写其编译器以在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. 新的统一工具链减少了代码大小，提高了可维护性。 灵活的工具链，便携性仍然至关重要。

根据语言的不同，您可能会有所不同。