Golang Go语言中为什么1.5版本要用Go重新写compiler?
今天看到 Go1.5 全部采用 Go lang 重新写了。
为什么抛弃 C, 是不是这样更快点？这样做法有什么优势吗？
Golang Go语言中为什么1.5版本要用Go重新写compiler?
为了实现自举吧。
更多关于Golang Go语言中为什么1.5版本要用Go重新写compiler?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
- It is easier to write correct Go code than to write correct C code.
- It is easier to debug incorrect Go code than to debug incorrect C code.
- Work on a Go compiler necessarily requires a good understanding of Go. Implementing the compiler in C adds an unnecessary second requirement.
- Go makes parallel execution trivial compared to C.
- Go has better standard support than C for modularity, for automated rewriting, for unit testing, and for profiling.
- Go is much more fun to use than C.
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit
我想您有地方理解不是很恰当。
大部分编译器生成的代码都是机器码，也可以等价的认为是汇编代码
然而汇编语言抽象层次不高，难以直接用汇编语言写出复杂的编译器
编译器不只编译，而且还做语法分析、代码优化等多种工作
用本语言写本语言的编译器是对语言功能的一种检验，也算是一个比较好的例子
第一个 C 语言的编译器当然不是用 C 语言写的，但是用 c 写出一个高性能的编译器在我看来绝对是对 C 语言性能的一个最好证明，也大概是 C 语言能风靡世界的一个重要原因
小弟一家之言，还基本上是重新整合了一下以前看过的几篇文章，您随便看看。。有什么问题咱们一起讨论
看了下 的回复，我理解下
第一个 go 编译器肯定是 c 写的，当 go 成熟之后，官方写了一个 c -> go 的转换器，将 c 写的 go 编译器代码 全部装换成 go 的代码。整个过程就是 用 c 语言作为一个桥梁，沟通了汇编 和 go
并不是。
编译器本身就是您说的桥梁，官方在 Go 成熟之后是用 Go 写了一个 Go -> 机器码 的转换器，并用之前的 C 语言 版的编译器将新编译器编译成可执行文件，从而达到 Go 语言可以编译 Go 语言 的目的
另外，您提到的 C -> Go 的转换器可以看成是翻译器，印象当中豆瓣网站就用了这样的工具将 Python 翻译成 C 以获得高性能。
你想创造一门 V 语言而且用 V 语言来写 V 编译器的话，你得按照下面的方法做：
1 、用 C++把那个编译器（ A ）写出来，顺便留下很多测试用例。
2 、用 V 语言把那个编译器写（ B ）出来，用 A.exe 来编译 B ，修改直到所有测试用例都通过为止。
3 、 B.exe 来编译 B 自己得到 B2.exe ，修改直到 B2.exe 所有测试用例都通过为止。这是为了保证，就算 B 本身有很多 bug ，至少编译自己是没有 bug 的，从而你就可以走到第四步。
4 、当你觉得有信心了，用 A.exe 把 B 编译一遍，就得到了 B.exe 。然后 A 的代码和 A.exe 都在也不需要存在了，删掉他们。以后你就不断的用 B.exe 来编译下一个版本的 B 就好了。就自举了。
说的很对，一个小瑕疵：
1. 用 X 语言将 A 写出来，并不局限为 C/C++ ，可以是任意语言
例子：汇编语言的汇编器没问题的话此处 X = 机器语言，
Ada 语言的编译器此处 X = 汇编语言
（另外不是所有的可执行文件都需要 .exe 后缀）
的例子很好
如你所说的话，那就是官方为了实现自举的话，得用 go 实现 go -> 平台特定（ x86 、 x64 、 PowerPC 等）的汇编码的过程，然后用平台特定的汇编编译器编译成可执行程序，这样理解正确吗？
有一部分编译器借助了这个过程，更多的是直接生成机器码
另外并不存在特定官方的说法，只是如今部分语言有主要推动者，出力比较多 (MS-Visual X / Apple-Swift&ObjC / Google-Go )。。。
如果不满意官方的，完全可以另起炉灶，或者在官方基础上形成分支，或者直接影响官方的版本
自起炉灶要大量的人力和财力去支撑，现在差不多用途的语言都有先来者占着了，除非有大公司撑腰或者社区有极大热情的，否则前景都不会太好。最典型的恐怕就是 dart 和 JS ， go 和 rust 了。
perl6 掉进坑里了，真是心酸， python 的 pypy 要是能发展快一点多好啊。
现在 Go 自举了，感觉编译也烦了。首先用 C 编译 1.4 ，然后又用 1.4 编译 1.5 。
是不是往后都这样？那不是要同时维护 1.4 和 新版本的代码库？？
（最近被项目的老代码搞烦了，掉前人坑里了）
刚刚在 freebsd 10.1 release 下 用 ports 安装 ports/lang/go ，最新的就是 go-1.5
因为 ports 是自动源代码编译，所以安装 go-1.5 就会依赖 go-1.4 ，
整个自动化过程：
先根据依赖自动安装 go-1.4 ，用系统自带的 llvm/clang 编译安装好 go-1.4 ，
接着使用 go-1.4 编译安装了 go-1.5
作为IT领域Go语言方面的专家，对于Go语言1.5版本用Go重新编写编译器（compiler）的决策，有以下见解：
Go语言1.5版本选择用Go重新编写编译器，主要是出于以下几个方面的考虑：
- 实现自举：这是Go语言发展过程中的一个重要里程碑，意味着Go语言已经足够成熟，可以用自身来编写其核心工具链，包括编译器。
- 提升性能：重新编写的编译器可能引入了多项性能改进，如更快的编译速度和更高效的垃圾回收机制。
- 跨平台支持：使用Go语言编写的编译器更容易实现跨平台支持，因为Go语言本身就具备很好的跨平台能力。
- 统一工具链：通过用Go语言重新编写编译器，可以使得整个工具链更加统一和简洁，减少维护成本。
- 技术演进：随着Go语言的发展，编译器也需要不断演进以适应新的语言特性和性能要求。用Go重新编写编译器是这一演进过程中的重要一步。
总的来说，Go 1.5版本用Go重新编写编译器是出于技术、性能和跨平台支持等多方面的考虑，这一决策推动了Go语言的进一步发展。
