Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration.

"Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with actual runtimes.

For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

"... the custom toolchain is one of the key reasons we've accomplished so much in so little time. I think the author doesn't fully appreciate all the reasons that C tools don't work well for languages that do so much more than C. Most other managed languages are doing JIT compilation and don't go through standard linkers either."

[1] https://news.ycombinator.com/item?id=8817990

> For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

LLVM now supports both segmented stacks [1] and precise garbage collection with patchpoints [2].

Tweaking support for segmented stacks is quite easy—I added the support for it on x86 Mac. You simply adjust the prolog emission code in X86FrameLowering.cpp and likewise for the other targets.

[1]: http://llvm.org/docs/SegmentedStacks.html

[2]: http://llvm.org/docs/StackMaps.html http://llvm.org/docs/Statepoints.html

Yeah, the point is that it wasn't there at that time.

> But I guess Google just hates Apple that much?

This is silly. Google contributes a huge amount to LLVM. They're very invested in the project.

(NB: I'm not defending, and don't agree with, the choice to avoid LLVM in Go.)

> the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code

It does not have platform-specific C code, as there is no more C code anymore. It sure does have platform-specific Go code and platform-specific assembly code though.

> from cgo's runtime so it can support the different architectures/platforms.

There is platform-specific code in the runtime, and there is platform-specific code elsewhere in the standard library, e.g. in the syscall package, but it's not from "cgo's runtime" (whatever that means). Go does not require cgo to interact with the target system, even on platforms where the interaction is done through shared libraries, not system calls, like Solaris and Windows.

> because it has platform specific C and assembly code from cgo's runtime

I'm not sure what you mean by "cgo's runtime", but go runtime is in go since 1.5. Some bits are still written in assembly but that's mainly for performance.

I don't think targeting every arch (and virtual archs like asm.js you mention [though there is a 3rd party GopherJS]) and OS out there was ever their purpose.

In case you're interested, there is llgo which has recently been merged into LLVM. It's still not practical however.

> But I guess Google just hates Apple that much?

I don't understand what this is supposed to mean since LLVM does not belong to Apple, and Google is a heavy user and contributer thereof.

> Some bits are still written in assembly but that's mainly for performance.

Many bits in math and crypto have fast assembly variants, but the assembly code in the runtime and sync packages is not for performance, but because assembly is the only way to put data in the right registers, issue memory barriers, implement the right atomic operations and so on. Not performance.