So you need 1.4 to build 1.5....can you then rebuild 1.5 from 1.5? Would it be different? 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?
> 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
I'm curious, as the document doesn't mention it, what is the benefit of bootstrapping? Is it primarily to allow future development to happen in the bootstrapped language, instead of the lower-level language (C in this case)? Or is there some other benefit I'm missing?
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.
Yes, that is a real risk. I have written about this before. It's much more of a risk at the start, when there are no other sizable programs. Now there are plenty of sizable Go programs, so I am not worried about overfitting to compiler development.
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!
I don't understand how the compiler's implementation language has any bearing on the design of the language it is trying to compile.
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.
Ugh...this is going to make new ports such a pain. I can understand why they're doing it, but this is going to make my life a lot more difficult.
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.
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.)
Well, if Go 1.4 is the last version almost entirely written in C, then for unsupported architectures/platforms, it seems like it would be the easiest to port first before bootstrapping a new version of Go. Is that not the case?
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.
I don't see much point to doing two ports (of very different versions of the code base) when you can do one port (of the current version, via cross-compilation) and then copy the result over to your target system and use that as the bootstrap base for future ports.
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'm not sure why I was downvoted into oblivion; but that's actually great news.
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.
For others following along, I would like to point out that my original conclusion was that 1.4 would be required given the explicit statement in the document:
To build Go 1.x, for x ≥ 5, it will be necessary to have
Go 1.4 installed already, in $GOROOT_BOOTSTRAP.
This is subtly different from the statement in the new ports section of the document:
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.
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.
> But Go only cross-compiles well for platforms and architectures it currently supports ;-)
This is an odd thing to say. Go cross-compiles exactly as well as it compiles. If you write a go_YOUROS_YOURARCH_exec script that copies the binary over to your target system and runs it, you can sit at any working system (for concreteness, any x86 system running Linux, OS X, or Windows) and work in a full Go environment. That's actually better than sitting on an unsupported system editing C files and unable to run any program written in Go.
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.
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..
I'm more surprised that the Go 1.4 compiler is written in C. Writing a compiler in C sounds very unpleasant compared to a language like OCaml. Does anyone know why they made this choice for the initial design?
Why does being a good coder preclude code reviews? Even experts make mistakes and even when there are no mistakes an outside perspective can often be useful. People think in different ways and may have something to add even if you are all really good programmers.
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.
> 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.
> 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.
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.
That article is misleading -- it's really about C++, not C, and isn't really relevant to the Go compilers (which are written in C). I have Coders at Work and I think Ken Thompson was exaggerating a bit for the humor of it.
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 :)
> Did he? I was under the impression he wasn't approved to write C at Google when Go was initially being developed.
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.
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.
