Hacker News Reader

Comment by travjones | Hacker News Reader

>"The compiler tool chain was translated from C to Go, removing the last vestiges of C code from the Go code base."

This is really cool. Writing a compiler in the language that you're compiling seems kind of meta. The language has evolved to a point to where it can consume and build itself. Far out mannnnn.

Thanks Go team!

View on HN

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.

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

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

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...

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.

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.

>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

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

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

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...

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.

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. ;)

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?

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.

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...

Reply on news.ycombinator.com