| While Go has a lot of clear influence from Plan 9, I don't see the "conspiracy theory" here at all. As far as I'm aware, one major reason why Go reinvented so much was to save time and effort. They did whatever they could in order to bootstrap fast and efficiently, and they did so by cannibalizing Plan 9's toolchain, including the compiler and assembly language. The original "gc" toolchain (with inscrutable binary names like "6g" and "6a"), was written in C and came directly from Inferno. You can browse the original commit here [2]. That stuff has all been rewritten in Go. A key attribute I and others have noticed about highly productive developers is that they tend to build an effective toolchain around themselves and bring it with them for new projects. Sometimes that stuff can become legacy baggage, but there's no denying that it's a good strategy. Perhaps LLVM or GCC would also have been a good strategy. There are some arguments to the contrary. 11 years ago, when Go was started, LLVM wasn't nearly as mature as today. But look at the hurdles other projects like Rust have had to get over with LLVM. And a large part of Rust's compilation speed is apparently due to LLVM. So LLVM is not a magic bullet. Migrating Go today to LLVM would of course be a big, time-consuming zero-velocity project; you'd want to be really certain that the payoff would be worth the effort. GCC is not an easy project to deal with, either. For decades, its internal intermediate representation was undocumented and intentionally obfuscated [2] to ensure FSF/GNU control over backends. I do agree that Go has a certain bias towards a particular, idiosynchratic way of doing things, which is not always a positive. [1] https://github.com/golang/go/commit/0cafb9ea3d [2] http://lambda-the-ultimate.org/node/715 |
I don't mean to imply that there's a conspiracy here. What I mean is that I think the Plan 9 heritage is clouding strategic decisions around the Go toolchain. What may have been the right decision to get a new language off the ground is not necessarily the right decision once the language is widely popular and stable.
> Migrating Go today to LLVM would of course be a big, time-consuming zero-velocity project; you'd want to be really certain that the payoff would be worth the effort.
A big project, yes, but it's happening! [3] If a few engineers working on gollvm for a year or two could improve gollvm to the point that it made the average Go program run 20% faster, I'd think that would absolutely be worth it to Google.
> GCC is not an easy project to deal with, either. For decades, its internal intermediate representation was undocumented and intentionally obfuscated to ensure FSF/GNU control over backends.
Very true in general, but the Go team has been lucky in that GCC core maintainer Ian Taylor has been a member since the early days. Gccgo has been a spec-conformant Go compiler since 2012 [2], and so nearly all of the GCC-integration bits have been in place for seven years. As a result, it's far more a matter of staffing the project so that the Go frontend's inliner, garbage collector, and escape analysis can reach parity with gc, rather than dealing with GCC/FSF politics.
> You can browse the original commit here. That stuff has all been rewritten in Go.
Yeah, I'm familiar with the lineage. I don't know that I'd say that it's been rewritten in Go, though, as the toolchain and runtime were converted fairly automatically with a "c2go" tool that Russ Cox wrote [0] around the Go 1.5 release. Have you looked at the resulting code much? Some of it has been rewritten to be idiomatic Go, but a lot of it is still very clearly C code that has been automatically translated [1]. See also the fact that go/src/runtime/runtime.go, go/src/runtime/runtime1.go, and go/src/runtime/runtime2.go all exist—a consequence of the fact that runtime.go, runtime.c, and runtime.h all existed in Go 1.4 [2].
[0]: https://github.com/rsc/c2go
[1]: https://github.com/golang/go/blob/7b294cdd8df0a9523010f6ffc8...
[2]: https://blog.golang.org/gccgo-in-gcc-471
[3]: https://go.googlesource.com/gollvm/+log