Building a Better Go Linker • Hacker News Board

Re: Building a Better Go Linker

#101

Post by slrz » Sat, Sep 14, 2019, 12:28 PM UTC

benesch wrote: post #26

What I would give for the developers of the Go toolchain to have spent the last decade improving GCC or LLVM instead of their own bespoke toolchain. In many ways Go seems like an excuse for Google to fund the continued development of Plan 9. Three of the five most influential people on the Go team (Ken Thompson, Rob Pike, and Russ Cox) were heavily involved in Plan 9. And it shows. Go's toolchain is a direct descenda…

> Indeed, for a while, the Go compiler was written in this special dialect of C, and so building Go required building a C compiler (!) that could compile this custom dialect of C, and using that to compile the Go compiler [2].

I don't think that's true. The build process used GCC to compile the Go and C compilers. The Plan-9-derived C compiler was used for compiling those parts of the runtime that were written in C back then and were supposed to follow the conventions of Go program code.

As you can tell from Inferno (or even Plan 9 from userspace), GCC can compile the Plan 9 C dialect, given the right options.

Re: Building a Better Go Linker

#102

Post by solresol » Sat, Sep 14, 2019, 3:09 PM UTC

ChrisSD wrote: post #7

derefr wrote: post #3

> its implementation fit in one Turing award winner’s head What a great unit of measure :)

Wait, how many London buses fit in a Turing award winner's head? And can they all fit in to Wales despite the number of Olympic sized swimming pools already there?

I think we also need to convert that into elephants and blue whales. What's the conversion rate for elephants to London buses?

Re: Building a Better Go Linker

#103

Post by sdrothrock » Sun, Sep 15, 2019, 4:57 AM UTC

slrz wrote: post #100

sdrothrock wrote: post #31

Earlier quoted context omitted.

I don't think that would be appropriate since Golang isn't (to my knowledge) under the GNU license. Maybe gocc?

Software licenses don't really matter if you implement the Go language spec with your own code. It's only when you want to share code with other implementations that software licensing enters the picture. Gccgo manages to share most of the standard library with the golang.org implementation, so they appear to have the licensing figured out.

I brought up the licensing originally since I thought they were spitballing a name and the "g" in "gcc" originally stands for "GNU."

So I was saying (mostly tongue-in-cheek) that it probably wouldn't be appropriate.

Sorry for the confusion, and I appreciate the clarification here too. :)

Re: Building a Better Go Linker

#104

Post by tatersolid » Wed, Sep 18, 2019, 1:33 AM UTC

benesch wrote: post #26

What I would give for the developers of the Go toolchain to have spent the last decade improving GCC or LLVM instead of their own bespoke toolchain. In many ways Go seems like an excuse for Google to fund the continued development of Plan 9. Three of the five most influential people on the Go team (Ken Thompson, Rob Pike, and Russ Cox) were heavily involved in Plan 9. And it shows. Go's toolchain is a direct descenda…

Go is supposed to be a concurrent, type-safe, memory-safe, systems programming language.

This goal is entirely at odds with an unsafe, legacy-ridden C/C++ toolchain.