On Thursday, 19 December 2013 09:11:07 UTC+11, rsc wrote:
A few weeks ago I sent out a doc about refactoring the linker, moving as
much as possible into the compilers and rewriting what remains of the
linker in Go. The refactoring is done, surely with some corner case bugs
introduced, and it has already made the linker faster. The new linker in Go
is in progress (very early, no CLs yet). That plan is at
Once the linker is done, we intend to move the Go compiler itself. [...]
I'm not much of a programmer but have been looking at Go recently and
playing around with it, and am happy with its minimalism and
understandability. When first looking at it, one of the things that made it
attractive was the decision not to write the compiler in Go. Seeing the
original post in this topic reminded me of what became of Haskell - seehttp://marc.info/?l=openbsd-ports&m=136796351325773&w=2
, and (later in the
same email chain) this nightmarish scenario:
"At the moment, I'm running a test-build of ghc-7.4 using ghc-7.0
bootstrapped from ghc-6.12 bootstrapped from ghc-6.10 boostrapped
from 6.6 bootstrapped from nothing but a (still machine and os
dependent) .hc file bundle on amd64 running inside qemu on the
desktop pc in my office (and -- whow -- it's crappy). If this
succeeds, and if the whole process also works on i386 without too
many additional fixes, the ghc port will survive at least until the
flag day and until I start to work on an update to ghc-7.6.3 and
The "flag day" referred to above was the switch from 32bit to 64bit time.
It seems overly-optimistic to assume that no such "flag day" (which occur
from time to time in OS developement) will stop a prior version of Go from
running (and therefore allow it to be available) for building the newer
version, notwithstanding that it is statically compiled or makes few system
calls does not deviate from Go1.0 or whatver.
If the switch to Go written in Go is to happen, it seems the way least
likely to destroy it over time is to bootstrap using gccgo rather than Go -
and also allow bootstrapping from llvm-go (if/when it comes along). In this
way the entire language would not be able to be held hostage by gcc
developers classifying a bug or two as "not to be fixed."
To end on a positive note, Go so far to me looks very good and after 3 or 4
years of development remains speedy and understandable. I note it is easier
to compile a program in Go than reply to an email chain in the
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.