> proudly declares that it will not use any modern advances to compiler technology
My apologies: this is an opinion, rather than an explicit declaration from the project. Their compiler "gc" starts with a traditional recursive descent parser using bison, and chose not to use llvm. Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. By having a common compiler infrastructure, compilers can focus on what is important. They currently have a simple parallel mark-and-sweep garbage collector, and there is some scope for development in the context of concurrent programs (wasn't it their goal to make it easy to write concurrent programs with goroutines?). Nothing spectacular though: the garbage collector in a mature JVM or V8 (which has to deal with a weakly typed language!) is far ahead; that's where the garbage collection research happens.
> what the final programs looks like is secondary concern
The grammar has been specifically engineered so that the language can be analyzed and parsed without a symbol table. "go fmt" is just syntactical sugar: you cannot change the underlying parser. I'm not bikeshedding about which syntax is "better", but pointing out the motivation behind the current syntax. For instance, it's very different from ruby, which was designed ground-up to resemble human language as closely as possible (hence Poignant Ruby etc).
Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it.
Actually, all serious Common Lisp implementations, for example, do incremental AOT compilation these days, and none of them is ever going to "move towards using LLVM". In the broader landscape of programming language implementations, as far as IR generality is concerned, LLVM is actually not significantly better than Java bytecode, and for many languages, trying to use it would probably generate more problems than actually using it would solve.
Right, gccgo. However, that does seem to be the dominant implementation: llgo is being developed as an education exercise (excerpt from project page). From the Go FAQ:
We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals.
The 'dominant' implementation is gc, not gccgo. IIRC, gc is based off the Plan 9 compliers which Pike et al write. gccgo is an alternative implementation which (generally) trails gc.
Most go programs that don't need to be linked with existing C libraries are using the gc compiler.
Currently there are a lot of really good C libraries that haven't been ported to go, so anyone who wants to link to those is using the gccgo compiler, but it will probably be less used as the native 3rd party libraries catch up, or the C libraries are ported (this is happening at a furious rate)
No need to apologise to me :-) As I said, you're entitled to your opinion.
You'll probably be interested in some of what was talked about in the "Go Fireside Chat" (http://youtu.be/p9VUCp98ay4) in regards to re-designing the compiler, alternate compilers, LLVM etc. It sounds like they're aware of exactly the issues you're concerned about.
My apologies: this is an opinion, rather than an explicit declaration from the project. Their compiler "gc" starts with a traditional recursive descent parser using bison, and chose not to use llvm. Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. By having a common compiler infrastructure, compilers can focus on what is important. They currently have a simple parallel mark-and-sweep garbage collector, and there is some scope for development in the context of concurrent programs (wasn't it their goal to make it easy to write concurrent programs with goroutines?). Nothing spectacular though: the garbage collector in a mature JVM or V8 (which has to deal with a weakly typed language!) is far ahead; that's where the garbage collection research happens.
> what the final programs looks like is secondary concern
The grammar has been specifically engineered so that the language can be analyzed and parsed without a symbol table. "go fmt" is just syntactical sugar: you cannot change the underlying parser. I'm not bikeshedding about which syntax is "better", but pointing out the motivation behind the current syntax. For instance, it's very different from ruby, which was designed ground-up to resemble human language as closely as possible (hence Poignant Ruby etc).
[edit: gc does not use a gcc backend; gccgo does]