Why does Go use its own Code generator?

The current, official compiler for Go (http://code.google.com/p/go/) currently uses a handcrafted, arguably arcane code generator, which includes injecting custom sections into the ELF Binary.

This approach has spawned quite a few bugs related to utilities that directly read and/or write ELF Information, such as ldd, objdump or strip.

I believe that this could have been prevented by using a welltested crossplatform code generator, such as LLVM, and then just use linking facilities shipped with the OS, such as ld on Unix/Linux (or ld.exe on windows w/ MinGW), or link.exe on Windows with Visual Studio.

So why does Go use its very own code generator? Is it really just reinventing the wheel? Or are there more important reasons behind it?

For information on how to use gccgo, a more traditional compiler using the GCC back end, see Setting up and using gccgo.

The Go Language Specification is compiler agnostic. You can choose from the available compilers, write one yourself, or contribute to the LLVM Go frontend project.

For an historical perspective on the Go compiler technology, read the answer to this question: What compiler technology is used to build the compilers?

The reference compiler (5g, 6g, and 8g, collectively referred to as gc) was written by Ken Thompson based on the C compiler he wrote for the Plan 9 operating system. There are a couple reasons he did this:

• He was already familiar with how his C compiler worked, so it was easier for him to adapt his existing work rather than learning an entirely new framework.
• One of Go's goals is to compile fast. The gc compiler is probably faster than an LLVM-based compiler could be because it's just not doing as much work. Then again, it's also not optimizing as well.

As Peter mentioned, there's also gccgo, which uses gcc as a backend. I suspect there will eventually be other options for Go compilers, especially given that the Go libraries include a complete Go parser and a (partially complete) type checker.