[dsymonds]

What's your counter-proposal?

If you're building a new language, you need a new AST. You can't represent Go source code in a C++ AST.

There are alternate compilers for Go, in the form of gccgo and llgo. But those are both very slow to build (compared to the Go tree that takes ~30s to build the compiler, linker, assembler and standard library). And the "gc" Go compiler runs a lot faster than gccgo (though it doesn't produce code that's as good), and compilation speed is a big part of Go's value proposition.

[chimeracoder]

> There are alternate compilers for Go, in the form of gccgo and llgo. But those are both very slow to build (compared to the Go tree that takes ~30s to build the compiler, linker, assembler and standard library).

For any non-Gophers reading this: I write Go as my primary language, and have for the past two and a half years. I just timed the respective compilation speeds on a handful of my larger projects using both gc and gccgo (and tested on a separate computer as well just for kicks).

gccgo was marginally slower, though not enough to be appreciable. In the case of two projects, gccgo was actually slightly faster. The Go compiler/linker/assembler/stdlib are probably larger and more complex than the most complex project on my local machine at the moment, but I think my projects are a reasonable barometer of what a typical Go programmer might expect to work with (as opposed to someone working on the Go language itself).

The more pressing issue as far as I'm concerned is that gccgo is on a different release schedule than gc (because it ships with the rest of the gcc collection). That's not to say it's not worth optimizing either compiler further when it comes to compilation speed, but it's important for people considering the two compilers to understand the sense of scale we're talking about - literally less than a second for most of my projects. Literally, the time it takes you to type 'go build' is probably more significant.

[dsymonds]

Thanks. That's good data. I haven't seen any measurements for a few years. It's good to see that gccgo has caught up. Which version of gc did you test?

Yes, the release schedule is another important reason for building our own toolchain. Being in control of one's destiny is often underrated.

[chimeracoder]

On this machine, gc 1.4.1 vs. gcc 4.9.2 (with no extra flags). My other machine has gc's tip, but runs Wheezy so it's probably an older version of gcc... it wasn't much different either way. I would barely have noticed it if I hadn't been timing it.

[arcticbull]

I would never set out to build a language I wanted people to use and not build it as a front-end for LLVM. I don't want to write an optimizer or assembler.

I don't doubt for one second that llgo takes a longer time to compile. And in exchange for slower compile times you benefit from many PHDs worth of optimizations in LLVM. And every single target architecture they support.

It's easy to build something faster when it does less. I'll admit there's no blanket right answer to that tradeoff.

[dsymonds]

Yes, that's why there's both gc and gccgo (llgo came later). Apart from the rigour of having two independent compilers, they are seeking different tradeoffs. gc is very interested in running fast, and gccgo benefits from decades of work that have been put into gcc's various optimisations.

Does that answer your original statement that you didn't understand why we build our own toolchain?

[bsdetector]

Well I still don't understand. Russ says it was for segmented stacks, but doesn't explain why those were necessary. You say it was for compile speed, yet gcc and llvm can crank out millions of lines a code a second at similar optimization levels as the Go compiler. Neither of these are convincing explanations.

[pjmlp]

Then you will be stuck with the C view of world of what a linker is supposed to do.

Just look at Modula-2 and Object Pascal toolchains as examples of compile speeds and incremental compilation features that could run circles around contemporanean C compilers.

Or the lack of proper module system, which requires linker help.