There is a good presentation from Pike talking all about the what/why/how of the C -> Go transition:

http://youtu.be/cF1zJYkBW4A

http://talks.golang.org/2015/gogo.slide

The term is self-hosting compiler, when a compiler can compile itself.

https://en.wikipedia.org/wiki/Self-hosting

As the old hacker snark says 'Any language that can't compile itself is a toy language'.

How has this affected compile speeds? Go proponents often tout the speed at which it compiles code as an important feature, so I wonder if there's been a noticeable regression.

Slower in the short term while the code remains transpiled from C. Will get faster as the team goes over it a couple times.

Yes, this is a good summary.

> Builds in Go 1.5 will be slower by a factor of about two.

https://golang.org/doc/go1.5#performance

The small increase in build times doesn't bother me at all when I'm generating a binary, but unfortunately it's very noticeable and irritating when using tools like vim-go or syntastic which type-check/lint/gofmt your code. Using these now causes vim to be unresponsive for up to a second every time I save, whereas the delay used to be insignificant.

> which type-check/lint/gofmt your code

Those tools do not use the Go compiler. They're using go/ast or go/types. So the translation of gc from C to Go can't have affected them.

They also build the source file, which is indeed much slower, to about 2x.

Perhaps things have improved since then, but this thread indicates build times will regress a little:

https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...

>This is really cool. Writing a compiler in the language that you're compiling seems kind of meta.

It's been done before, for more than one language, IIRC.

The technique by which they make an executable of a compiler for language L on platform B, using an existing executable of the same compiler for L on platform A, together with the source code of the compiler for L on A, is also cool. I forget the full details right now. Maybe someone else will pitch in and explain. It's called bootstrapping. It's also related to cross-compiling.

Update: Looked it up in Google:

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

https://en.wikipedia.org/wiki/Cross_compiler

Also see Canadian Cross under above article - this is like the cool technique I talked about above, but more complex.

TypeScript does the same thing - its compiler is written in TypeScript. See https://github.com/Microsoft/TypeScript/tree/master/src/comp.... But yeah, darned cool, and very meta.

Perhaps this is a dumb question, but what language was used to compile the compiler? Was it compiled in C? Surely it must have had to of been compiled in a different language somewhere down the chain.

It is built with Go 1.4. Details: https://golang.org/s/go15bootstrap

yes.. golang's compiler was originally in C. The process is called bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

The 1.5 build requires you to have a go1.4.2 build which is used as the bootstrapping compiler.

well, it's actually turtles all the way down.

Although you can end up with fun situations like the C compiler backdoor: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-de...

You can start from the C version and move forward and check that you get the same result as starting with released Go binaries.

Unless you think Ken somehow backdoored the original C compilers to backdoor every C compiler in the world to backdoor the Go compilers that came about decades later. :-)

Seems simpler to just backdoor the linker/library archiver, that way almost all toolchains are backdoored. ;)

Haven't read the article you linked to, but the Brian Kernighan talk it discusses is fantastic, one of my favorite reads in the field:

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

That's ken, not bwk.

D'oh. Thanks.

This might be a dumb question: What happens if you find a bug in the language? Let's say something that you had written in C was being misinterpreted, and now the go compiler still uses that byte-code to compile new versions of the compiler.

Or is that something that isn't really possible?

You should read Reflections on Trusting Trust, it expands on this idea in the most beautiful way: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

I think Russ showed the translated code produces the same binaries as the Go 1.4 C variant. So this isn't very likely given he has the option to pipe roughly any Open Source Go project through the compiler.