3 ms·
> If you want to take the code and run off with it in the sunset, you're perfectly able to do so. Instead of at least re-using/borrowing code from LLVM, they de
by kaib 16y ago
> If you want to take the code and run off with it in the sunset, you're perfectly able to do so. Instead of at least re-using/borrowing code from LLVM, they decided to embark on a rather laborious and difficult aspect of language development themselves with zero input from other projects.
I think there are two separate concerns, both which I'm disagreeing with you on. First, my understanding is that when ken wrote the initial compilers he wanted to focus on the frontend and re-use a backend. So he picked the plan9 compilers which he knew well (they predate LLVM by 10 years and he mostly wrote them). There was very little original work going into the code generation.
Second, I think you are grossly underestimating the initial cost of integrating with an open source project unkown to someone. The first Go compiler frontend was written in a few weeks or months. I'm guessing that having to pick up a new unknown backend (LLVM) and language (C++) would have set the project back enough to make it miss it's window of opportunity.
It seems to me that your argument is that an incorrect choice was made in what to re-use. That seems like a very different thing than NIH.
> ARM compatibility
ARM compatibility had nothing to do with the decision to re-use the plan9 compilers. I'm a compiler neophyte and when I wanted to add ARM support to Go it was an easy choice to go with the existing framework (there was a solid plan9 C compiler for ARM). If I had tried to port the system to LLVM at the same time as adding ARM support my skills would probably have failed me.
> fast compilation
One of the distinctive features of the optimizers ken wrote for plan9 C, which are used in Go, is that they are much simpler and faster than normal optimizers but produce less optimal code. The GCC Go compilers are slower and slightly less comprehensive but produce code of higher quality. LLVM would undoubtedly produce better code as well. I'm happy to go into more technical detail if you want to, it would help if you'd let me know how much practical compiler writing experience you have?