undefined | Better HN

0 pointsarcticbull11y ago0 comments

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.

0 comments

dsymonds11y ago

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?

bsdetector11y ago

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.

pjmlp11y ago

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.

j / k navigate · click thread line to collapse