Go 1.5 Bootstrap Plan (opens in new tab)

> So you need 1.4 to build 1.5....can you then rebuild 1.5 from 1.5?

If the language is forward-compatible, yes. It could be different if new optimisations have been added, or the code generator has changed.

> Would it make a difference if you then rebuilt 1.5 using 1.5 built using 1.5 rather than 1.5 built using 1.4?

It should not, the 1.5 compiler should be stable and yield the same result whether it was built using a 1.4 compiler or a 1.5 compiler.

That's actually a common technique to look for regressions and validate the bootstrapped compiler. For instance to compile rustc you download a "stage 0" compiler at Vx which compiles a "stage 1" compiler using Vy > Vx source. That stage 1 compiler is then used to compile the stage 2 compiler from the same source. Stage 1 and stage 2 may not be identical since stage 0 and stage 1 may have different optimisations &al, so the stage 2 compiler is used to compile rust a third time, and that compilation is checked against the original stage 2 (and should be a fixpoint).

That's actually a step in bootstrapping the system. Generally, to bootstrap a language a new language involves building a minimal bootstrap compiler/runtime that is just enough to be able to rebuild the full system:

1. build bootstrap system with existing tools 2. compile full system with bootstrap 3. compile full system again with new compiler

Or something like that.

Edit/Note: The OP linked document is a pretty good explaination of the whole process as well as the implications ...

If both compilers are correct, which compiler you compiled the program (compiler in this case) with shouldn't matter for the correctness of the code; but the generated code would be different. There should be no difference in the code generated by instances of the same compiler version, although the code of the compiler programs itself would be different (i.e. different performance, time of exec...) if they were compiled with different compiler versions.

Edit: That's all assuming same version of the language being compiled. That's why they say the go1.x compilers may need to stay restricted to go 1.4 for their code.

P.S. See Linux From Scratch or osdev.org for more about this

Yep, exactly. We want to write our compiler in Go, now that the language and libraries are good and stable.

It's a process we started more than a year ago: http://golang.org/s/go13compiler

Bootstrapping has the benefit that the whole compiler toolchain can enjoy the usage of the language.

Additionally it is a way to expose the language designers to possible issues in the language, as they will spend more time using it instead of other implementation language, which helps improving its design and tools.

Personally I tend to favour bootstraping, even if it is a little inconvenient when porting to new architectures.

Microsoft found themselves unable to improve the C# language using a compiler written in a lower level language like C/C++ so they've rewritten it in C# to allow further language development and to support more sophisticated language features.

It also has the benefit of the team implementing the language actually dogfooding it, causing natural evolutionary improvements.

I suspect Google is doing this with go for the same reasons.

Also, there is no dependency on 1.4 being "long-term supported". I think you have the dependency requirement backward.

For the foreseeable future, it must be possible to build the compiler with Go 1.4. That means the compiler must stick to Go 1.4 libraries and constructs (or use build tags for conditional compilation). It says nothing about which version of Go you have to use to build the compiler. If we're working on Go 1.9 and you want to use Go 1.7 as the bootstrap base, that's fine: Go 1.7 will build and run everything that Go 1.4 does. You just can't introduce any Go 1.7-specific code into the compiler.

I don't know if you've noticed, but there are very few language changes in each release. We're focused on improvements to performance and reliability more than new features. So I don't anticipate it being a hardship that the compiler is limited to Go 1.4. (And that's still much nicer than C.)

What new ports are you working on? (I'm just curious.)

Go is already very good at cross-compiling. That can be used to do a new port (as a trivial example, the fact that the compiler doesn't run on NaCl didn't hurt the NaCl port at all). There is a section in the doc explicitly about this. We are doing new ports too (like power64), and I don't anticipate the bootstrapping change slowing them down appreciably.

I'm not sure I understand why this makes ports harder.

Shouldn't it be possible to port to a new system simply by porting Go 1.4 to that system? Once that base version is ported, a script can build 1.4, then build 1.5 and any succeeding base versions until the current version is reached.

Of course, system-specific features would have to be added for each go release beyond 1.4, but that would have to be done anyway.

What am I missing?

I don't understand why you need a bootstrap toolset in C.

Does go not support being cross compiled/cross compiling?

Can't you just write code generation for platform Y while on platform X? I guess you would have to do a bit of copying files around while debugging, but that shouldn't be the main issue when porting a system like this..

Ken Thompson wrote it. He's pretty good at C.

The Go compiler in 2007 was written in C because it was an adaptation of the Plan 9 C compiler. That was done because it was the expedient choice at the time, especially while the language was still being designed and would change quite a lot. Nowadays the language is stable, and we have existing Go compilers, so we can reasonably bootstrap a Go compiler written in Go.

One advantage is that nearly any system has a C compiler.

[1] http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b15d2ba7eb3a25...

C isn't as bad for compilers as it is for servers.

It should be pretty easy for distributions, since they'll already have packaged versions of Go 1.4.

Why? When you have built version 1.5 once using version 1.4, you can build 1.5 (or any future version that is source compatible) with 1.5.

The idea is not to not rely on C. The idea is to not have to do the compiler development in C.