6 ms·
There's an "official answer" in the FAQ [1] ("We considered using LLVM for gc but we felt it was too large and slow to meet our performance goals." Note: lowerc
by akavel 11y ago
There's an "official answer" in the FAQ [1] ("We considered using LLVM for gc but we felt it was too large and slow to meet our performance goals." Note: lowercase gc refers to Go compiler, whereas uppercase GC would refer to Garbage Collector). That said, I seem to recall other additional/more detailed reasons were given on various occasions too, including:
- ease of iteration and freedom to make huge breaking changes (and they did make use of it, see e.g. various generations of the GC, or the SSA work);
- thorough knowledge of the internals of the compiler they used (given they were it's authors; also this is linked to the reason I listed above);
- one of the explicit goals for the Go toolchain was that it must compile very fast (which I believe is also somewhat at odds with advanced optimizations, like those used in LLVM) - they even quipped something like "we designed Go while waiting for C++ to compile";
- additionally, though I'm not sure if it was ever spelled explicitly, I suppose they wouldn't want to get tied to the LLVM as a huge dependency, including having to adjust to each and every change in LLVM API, regardless if sensible or not (I seem to recall from so me articles that LLVM does introduce breaking changes in API from time to time?);
[1] https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
- witty_username 11y ago> which I believe is also somewhat at odds with advanced optimizations, like those used in LLVM You can configure the optimization level to 0, then only constant folding is performed when the IR is built, and nothing else is done.
- exDM69 11y agoYes, GC is a big issue... or was back when Go was just getting started. GC support in LLVM should be MUCH better now. Ie. it has everything you need to hook up a GC in it, but there isn't a built-in GC in it. And the fact that the first people working on Go have a good knowledge of the Plan9 toolchain probably gave them a head start. But that benefit has probably eroded long ago. And I completely disagree with the Go team's emphasis on compile times. Fast result programs are far more important than fast compile times. Fast compile times are nice to have, but not much more than that. But this is just my opinion, it's as good as anyone else's.
- iampims 11y agoFast compile times let you use Go as a scripting language, which has been key to its adoption from the python/ruby community. Fast compile times also let you run your test suite every time you hit ctrl + s. Fast compile times also let you run tools like gomft without feeling like it is slowing you down. I agree that fast programs are essential and (ideally) not mutually exclusive with fast compile times.
- pcwalton 11y ago> I agree that fast programs are essential and (ideally) not mutually exclusive with fast compile times. They are. It is always a tradeoff.