Go 1.5 Bootstrap Plan(docs.google.com) |
Go 1.5 Bootstrap Plan(docs.google.com) |
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).
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 ...
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
It's a process we started more than a year ago: http://golang.org/s/go13compiler
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.
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.
On the other hand, a big risk is that the language will evolve towards being better at writing compilers, which is a highly idiosyncratic task.
You should be able to write an O'Caml compiler in javascript or a Haskell compiler in C.
Rewriting the compiler in C# has the advantage of now being able to offer the compiler as a service to the C# run-time but not sure I see how it could have affected the design of the language.
If 1.4 is going to become the bootstrap toolset, that also suggests that 1.4 will essentially become "long-term supported", meaning that if new ports require fixes to the bootstrap toolset (even in the cross-compilation) scenario, hopefully they'll accept those changes upstream.
Interviewer: Was there any concept of looking at each other's code or doing code reviews?
KT: [Shaking head] We were all pretty good coders.
http://www.theregister.co.uk/2010/04/21/ken_thompson_take_ou...
Indeed he is. All the more reason for code reviews. [;]
[1] http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b15d2ba7eb3a25...
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.)
I don't feel like I have this backwards at all.
I wasn't commenting on it being a hardship to limit the implementation to Go 1.4's feature set.
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.
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?
Does go not support being cross compiled/cross compiling?
I jest, but, "ha ha only seriously". It's an interesting problem when writing languages in themselves, that you need to try not to make your language great for writing compilers and nothing else!
There is a "readability" process for C++, which is the thing he says he never got. Not much code is written in plain C -- the Go compilers would be an exception.
If I recall correctly, the book Coders at Work also talks a bit how the some of the Go/Plan 9 guys sat near to Bjarne while he was developing C++ at Bell Labs. They are not really fans :)
It's not that strict.
Google has a big source repository which holds essentially all applications which run on Google's production machines. (They share a lot of library code.) In this repository, code written in any of several languages must have been written or approved by someone who has "readability" in that language. There's no C readability, but C++ readability applies to files ending in .cc or .h. (Not sure about .c.) There's no shortage of people around with C++ readability, so Ken wouldn't have had a hard time getting anything approved. He also could have easily gotten readability if he wanted it.
This process wouldn't necessarily apply at all to separate git/Mercurial repositories used by open source things like Go.
Use your local git(1) for better history browser.
The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle.
I think the opposite is true. Good programmers know where the risks of subtle bugs are, and will use the appropriate tools (e.g. good use of a decent type system, well documented code with well designed abstractions) to make completely sure they don't exist.
This just leaves simple stupid bugs in the parts of the code where any such bug will manifest itself quickly and obviously, exactly the kind of thing caught by code review.
Another way to put it would be: good programmers design their code in such a way that all bugs are catchable by code review.
That's just arrogance. Good programmers make stupid mistakes all the time as well. It's the ability to recognize and fix such mistakes that separate "good" programmers from "normal" programmers and that's precisely where code review comes in.
For example, Go 1.4 did not support linux/ppc64, but Go 1.5 will. If you want to build Go 1.5 for linux/ppc64 from source, the simplest thing to do is to cross-compile it on a linux/amd64 system, copy the resulting binaries over to your linux/ppc64 system, and use that toolchain as the bootstrap base for any future work.
Doing two ports would work, but the first one is basically wasted effort unless you need to survive every other supported Go system disappearing tomorrow.
I was under the impression from reading the boostrap document that this meant I would have to port 1.4 and 1.5. I think I completely misunderstood the new ports section as to how it related to the plan overall.
If I can get away with only porting a newer version, that's considerably easier.
Thanks for assuaging my fears.
To build Go 1.x, for x ≥ 5, it will be necessary to have
Go 1.4 installed already, in $GOROOT_BOOTSTRAP.
For Go 1.x (x ≥ 5), new ports will have to be done by
cross-compiling test binaries on a working system,
copying the binaries over to the target, and running and
debugging them there.