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

71–80 of 104 posts

Re: Building a Better Go Linker

#71

Post by dullgiulio »

nn3 wrote: post #34

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.

Besides the fact that static linking has a lot of benefits, shared libraries need to be linked too: just this process is called "loading" and the linker is called "loader".

Worse, this needs to happen at every executable invokation.

Re: Building a Better Go Linker

#73

Post by warent »

miki123211 wrote: post #72

Anyone else is getting a "you can't view this page because you're offline" error? I don't know why this is happening, how does it even load when I'm supposedly offline?

It's probably being overloaded with too much traffic. The link is a Google Doc, and singular google docs aren't really great at handling traffic spikes.

Re: Building a Better Go Linker

#75

Post by Gibbon1 »

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…

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

Yeah the creators of go didn't come to praise C++ but to bury it. To kill C++ you need first to knock out gcc and LLVM.

Re: Building a Better Go Linker

#76

Post by foldr »

apta wrote: post #63
hu3 wrote: post #53

Earlier quoted context omitted.

What you vaguely label as poor design decisions are actually trade-offs and they make sense to a plethora of highly educated engineers.

The people who made golang are not language designers, and/or did not research established options in other language as per their admittance.

>The people who made golang are not language designers,

I bet they've designed and executed on more programming languages than you have :)

Re: Building a Better Go Linker

#77

Post by jbarham »

apta wrote: post #62
jbarham wrote: post #57

Earlier quoted context omitted.

Imagine what Ken Thompson could have accomplished if he hadn't made all those poor design decisions! And yet hundreds of thousands of working programmers around the world are productively using Go while still continuing to ignore the supposedly superior solutions.

Appeal to authority fallacy. People still use C, what's your point? There are superior options, but people are either (1) forced to use something inferior, or (2) don't know any better (especially if they drank the kool aid).

> people are either (1) forced to use something inferior, or (2) don't know any better

Here's another fallacy for you: false dilemma.

Re: Building a Better Go Linker

#78

Post by jorams »

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…

This is a minor point, but:

> What other language ships its own assembler?!

The majority of native code compilers I have seen include their own assembler. Many of them don't have a textual input format, but they are assemblers nonetheless.

Re: Building a Better Go Linker

#79

Post by 4ad »

kccqzy wrote: post #35
nappy-doo wrote: post #18

Earlier quoted context omitted.

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).

The Windows port never used raw system calls.

The Solaris port never used raw system calls.

The MacOS port doesn't use raw system calls since go 1.11.

The remaining ports for Linux/BSDs/Plan 9 have a stable syscall interface.

Post reply on HN