I don't understand how writing the Go compiler from scratch in Go is going to make it better than super-mature compilers. Wouldn't it better to leverage Clang/LLVM? Redoing all the optimizations by rewriting the whole compiler in Go seems like it will significantly delay performance parity.

For what it's worth, the go team's plan is to automatically translate the compiler to go, not to rewrite it from scratch:

http://talks.golang.org/2014/c2go.slide#18

And, the gccgo compiler does leverage gcc, assuming that counts as a mature compiler:

http://blog.golang.org/gccgo-in-gcc-471

. Neither of these contradict your implicit point of "they chose to invest time in this port instead of trying to maximize performance ASAP", but you still might want to know.

Seems weird to fork a compiler like gcc or clang via transpilation, because you split the community. It may be faster to iterate on Go, but will all of the compiler contributors on GCC or Clang/LLVM want to switch to editing the go version?

It seems you'd lose out on picking up improvements from the main compiler branch and have to keep transpiling and gardening in patches. Plus upstreaming improvements would also be irritating.

I'd think a Go frontend to LLVM would be optimal in terms of productivity.

The go compiler is based on the plan9 c compiler, not gcc. I'm not quite sure what the story is with gccgo (who initiated it, why) - but i think it was for interfacing with c on non-plan9 architectures, and not really about leveraging gcc optimizations.

gccgo was written by a gcc developer for the purpose of trying out new ways to write a frontend, but also to use all the various things gcc has.

https://blog.golang.org/gccgo-in-gcc-471

The Go developers have claimed LLVM was not useful because it's too slow, which is why they used the plan9 compiler style.

Go is a spec, not a compiler.

I don't think being written in Go will make the compiler produce intrinsically fast code. Rather, it will be easier for them to iterate. It is much faster to develop in Go than in C.

Go can already leverage some of gcc's optimizations. There's also https://github.com/go-llvm/llgo

They haven't written the optimizing compiler yet. They are waiting.

Wouldn't an optimising compiler run contrary to go's goal of fast compilation?

They could use the same front end and enable optimisation passes in the backend with compile flags / heuristics. GHC for example uses for certain flow optimisations "fuel" once it runs out it stops doing further optimisations. For long running applications, ideally the runtime would profile the application during its execution and JIT / optimise based on the live state of the application. The JVM demonstrates that this can have major benefits over AOT compilation.

No, going fast is about not doing work twice. It is about the dependency graph. Go was developed to make dependency analysis very simple, so you recompile a tiny number of files even on massive, complex apps... and don't spend massive amounts of time deciding what to compile, or building stuff up just to tear it down (include all the things, use macros to exclude, etc).

Unless they had a flag... I would think so.