Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Better Go Linker

golang.org

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Building a Better Go Linker

#31

Post by sdrothrock »

ksherlock wrote: post #30
Solar19 wrote: post #27

I like it. What would also be cool is another Go compiler and linker, developed by a different team not at Google. It would be good for the ecosystem and performance if there was more than one compiler and runtime. I think there would be a market for a proprietary compiler and maybe an IDE to go with it — if the performance was better than the open source one. I think this is achievable because as good as Go's perfor…

gccgo perhaps?

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

Maybe gocc?

Re: Building a Better Go Linker

#32

Post by jbarham »

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…

Given that Apple are the major sponsor of LLVM and they're not exactly cash poor, I think it's reasonable to conclude that being able to throw money and people at LLVM development doesn't explain why it's still much slower than the Go compiler toolchain. In hindsight the Go team made the right call to use their own toolchain.

As enneff alludes, Ken Thompson's antipathy towards C++ is well documented: https://bryanpendleton.blogspot.com/2009/12/coders-at-work-k...

Re: Building a Better Go Linker

#33

Post by chewxy »

Solar19 wrote: post #27

I like it. What would also be cool is another Go compiler and linker, developed by a different team not at Google. It would be good for the ecosystem and performance if there was more than one compiler and runtime. I think there would be a market for a proprietary compiler and maybe an IDE to go with it — if the performance was better than the open source one. I think this is achievable because as good as Go's perfor…

GCCGo,llgo and tinygo are different Go compilers built and maintained by different peoples

Re: Building a Better Go Linker

#34

Post by nn3 »

Who would have thought that statically linking hundreds of MB worth of binaries every build causes problems?

Maybe some of it can be fixed with a lot of engineering effort, but the fact remains that it is a bad idea to redo so much work every time.

Maybe the people who invented shared libraries had a point after all.

Of course the real problem is software and dependency bloat, but that is unlikely to ever get fixed.

Re: Building a Better Go Linker

#35

Post by kccqzy »

nappy-doo wrote: post #18
jacobush wrote: post #11

I hoped they would fix how the linker uses private OS calls.

Which private OS calls. Can you site what they are?

I'm guessing GP refers to the fact that Go binaries use raw system calls even on operating systems where the syscall boundary is considered a private implementation detail (which is the case on Windows and macOS).

Re: Building a Better Go Linker

#36

Post by wahern »

AlexB138 wrote: post #14

Any recommendations on resources to better understand the build process for compiled languages in general, and Go in particular?

Write your own simple virtual machine[1] and a tiny assembler which accepts symbolic names for jump targets (e.g. goto LABEL). You'll need a link phase to resolve the symbolic names, and all will become clear. A few hours of time and anything involving linking, addressing[2], and so much more will instantly become intuitive to you.

[1] Array of opcodes indexed with a program counter (pc) with a giant switch statement for executing each opcode. A simple stack for data implemented as an array and a stack pointer/index (sp). There are plenty of examples online, just make sure you actually implement things yourself, and only go to the examples to answer questions you arrive at yourself. If you understand loops and arrays implementing the VM is trivial. If you can parse a text file line-by-line and split words, implementing the assembler is trivial. Working out the linking might take some thinking, but that's the point. It's like one night of work, max, unless you really get sucked in ;)

[2] E.g. Harvard architecture vs. von Neumann architecture

Re: Building a Better Go Linker

#37

Post by loudmax »

enneff wrote: post #28
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…

> the state of compilers would be much better off if the folks on the Go team had invested more in improving the compile and link times of LLVM or GCC It never would have happened. How do you motivate people whose principal frustration is the state of C++ to work on a large C++ codebase? Heterogeneity is a huge benefit to any ecosystem. Improving existing things is great, but building new things is also very importan…

Agreed. This argument comes up a lot, especially in open source, that resources on one project would have better spent on some other project. Developer focus is not a fungible commodity. If the Golang devs hadn't been developing the Go compiler, they wouldn't necessarily have spent their efforts on LLVM, they'd just as likely be working on something other way to make Plan9 come about.

Re: Building a Better Go Linker

#38

Post by nemo1618 »

enneff wrote: post #28
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…

> the state of compilers would be much better off if the folks on the Go team had invested more in improving the compile and link times of LLVM or GCC It never would have happened. How do you motivate people whose principal frustration is the state of C++ to work on a large C++ codebase? Heterogeneity is a huge benefit to any ecosystem. Improving existing things is great, but building new things is also very importan…

100% agree -- enthusiasm is not fungible! Sometimes starting over is faster than incremental improvement.

Re: Building a Better Go Linker

#39

Post by geodel »

Solar19 wrote: post #27

I like it. What would also be cool is another Go compiler and linker, developed by a different team not at Google. It would be good for the ecosystem and performance if there was more than one compiler and runtime. I think there would be a market for a proprietary compiler and maybe an IDE to go with it — if the performance was better than the open source one. I think this is achievable because as good as Go's perfor…

> I think there would be a market for a proprietary compiler and maybe an IDE to go with it

There may be a market but not large enough to pay few top notch compiler/low level system software hacker. I only know of a commercial Go IDE and constant refrain there is how will a poor third world developer afford it. Though I feel real issue is developers are raised on diet of free software feels entitled to it. Paying for good software seems alien to them.

Re: Building a Better Go Linker

#40

Post by jerf »

sdrothrock wrote: post #31
ksherlock wrote: post #30

Earlier quoted context omitted.

gccgo perhaps?

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

I think you may misunderstand the nature of the post: https://golang.org/doc/install/gccgo

It's a thing that exists, not a proposal.

Post reply on HN