“This change deletes the C implementations of the Go compiler and assembler”

Post by dsymonds » Tue, Feb 24, 2015, 4:58 AM UTC

chimeracoder wrote: post #100

dsymonds wrote: post #94

Earlier quoted context omitted.

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 p…

> 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…

Post by chimeracoder » Tue, Feb 24, 2015, 5:05 AM UTC

dsymonds wrote: post #101

chimeracoder wrote: post #100

Earlier quoted context omitted.

> 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…

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.

Post by seryoiupfurds » Tue, Feb 24, 2015, 5:26 AM UTC

evmar wrote: post #104

arcticbull wrote: post #91

I still just don't understand why they insist on building their own toolchain. It just doesn't make sense to me. When you set out to build a programming language, what is your objective? To create a sweet new optimizer? To create a sweet new assembler? A sweet new intermediate representation? AST? Of course not. You set out to change the way programmers tell computers what to do. So why do this insist on duplicating:…

I read somewhere (but I can't think of the keywords to find it now) that they found the greater flexibility in owning their toolchain was worth the cost. For example they changed their data layout for GC purposes and changed the segmented stack approach over the course of their development and had they been tied to LLVM or gcc they'd have spent much of their time fighting against those implementations, or politicing…

Post by mseepgood » Tue, Feb 24, 2015, 6:32 AM UTC

arcticbull wrote: post #91

I still just don't understand why they insist on building their own toolchain. It just doesn't make sense to me. When you set out to build a programming language, what is your objective? To create a sweet new optimizer? To create a sweet new assembler? A sweet new intermediate representation? AST? Of course not. You set out to change the way programmers tell computers what to do. So why do this insist on duplicating:…

Post by nullc » Tue, Feb 24, 2015, 6:38 AM UTC

chimeracoder wrote: post #74

davexunit wrote: post #73

Here we go again. Another compiler that can't be bootstrapped from source code. It's a packaging nightmare. Another magic binary to trust not to have a Thompson virus.

> Another compiler that can't be bootstrapped from source code. It can be bootstrapped from source - it just needs to be bootstrapped either using gccgo[0], or using the 1.4 compiler (which is guaranteed to work for all 1.x compilers, not just 1.5) > Another magic binary to trust not to have a Thompson virus. "Reflections on Trusting Trust" gets posted on HN regularly, and it's an interesting exercise, but you are fa…