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

61–70 of 104 posts

Re: Building a Better Go Linker

#61

Post by benesch »

tylerl wrote: post #55
benesch wrote: post #42

Earlier quoted context omitted.

Let me refine my point a bit. Apologies; my original post had gotten a bit long. I agree that enthusiasm is important! And indeed, for the Go creators, their particular leanings might have been such that they couldn't get excited about building an LLVM/GCC frontend, and adapting the Plan 9 toolchain is literally the only way those three could have Go gotten off the ground. As a member of the Go team, you'd certainly…

> it is several years past due for Google to start investing seriously in a Go toolchain based on a mature compiler stack. That's a bit presumptuous, prescribing specific implementation details based on the fact that it's "several years past due" that they replace their tech stack with one you would like to see improved. Remember there already is a mature C compiler alternative for Go: gccgo. There's also already a f…

> Remember there already is a mature C compiler alternative for Go: gccgo. There's also already a first-party LLVM based Go toolchain created by Google (gollvm). Whatever hypothetical benefits you might presume would emerge from this kind of synergy already exist. But the community mostly isn't interested.

I suspect the community is uninterested because it’s hard to be interested in compilers that a) compile slower than gc, and b) produce slower code than gc. That's a worse compiler on all fronts!

For gccgo or gollvm to be useful, they need to provide some benefit. I suspect we'll see (b) fixed within a year. GCC/LLVM have far more optimizations than gc, and so it's mostly a matter of plumbing enough information from the Go frontend into the LLVM optimizer to unleash its full power.

I don't expect we'll see (a) fixed, unless something changes at Google.

> Also, Google also already invests a massive amount of resource into LLVM. In fact, the principal author of LLVM and Clang works at Google. But even when he was at Apple they were already shoveling resource into the project.

Yes, but Chris Lattner is not actively working on speeding up LLVM. His big project lately has been supporting TensorFlow via MLIR.

Re: Building a Better Go Linker

#62

Post by apta »

jbarham wrote: post #57
apta wrote: post #52

Earlier quoted context omitted.

The same people who created a language with poor design decisions where superior solutions existed in other languages they could have simply used?

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

Re: Building a Better Go Linker

#63

Post by apta »

hu3 wrote: post #53
apta wrote: post #52

Earlier quoted context omitted.

The same people who created a language with poor design decisions where superior solutions existed in other languages they could have simply used?

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.

Re: Building a Better Go Linker

#64

Post by pjmlp »

jbarham wrote: post #57
apta wrote: post #52

Earlier quoted context omitted.

The same people who created a language with poor design decisions where superior solutions existed in other languages they could have simply used?

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.

Imagine how famous he would be if Bell Labs had been allowed to sell UNIX instead of giving its source code away with a symbolic price.

Hundreds of developers used Basic, Pascal, C, Modula-2, Assembly, Forth productively.

Maybe we should have kept using them, instead of coming up with programming languages that require a PhD. /s

Re: Building a Better Go Linker

#65

Post by pjmlp »

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.

Just like when C came around and everyone else was doing safe system programming in Algol dialects, PL/I, Fortran extensions, BLISS, Mesa.

I see a trend here.

Re: Building a Better Go Linker

#67

Post by journalctl »

ori_b wrote: post #15
AlexB138 wrote: post #14

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

https://www.amazon.com/dp/1558604960

I just bought this! It’s fantastic and definitely still more than relevant for understanding the subject.

Re: Building a Better Go Linker

#68

Post by axaxs »

slx26 wrote: post #13

I love to see that at the end the document the plugins package is mentioned. Currently it doesn't have support for Windows (among other issues), so it's really good to hear that the work in the linker might eventually improve the situation with plugins too, and that at least it's being kept in mind. On golang, interfaces being implemented implicitly is not everyone's cup of tea, and I can understand why, but when you…

agreed. Just yesterday I was reading about shared object support in Go, and it hasn't improved since inception. Sometimes I just want an object/module, and not a git repo. Even VB had this down.

Re: Building a Better Go Linker

#69

Post by jart »

nappy-doo wrote: post #22
slx26 wrote: post #13

I love to see that at the end the document the plugins package is mentioned. Currently it doesn't have support for Windows (among other issues), so it's really good to hear that the work in the linker might eventually improve the situation with plugins too, and that at least it's being kept in mind. On golang, interfaces being implemented implicitly is not everyone's cup of tea, and I can understand why, but when you…

Plugins are hard, and very OS dependent. There's plenty about the current system that is fragile, and likely to cause problems. I think it's likely the linker rework needs to happen before plugins can be properly addressed.

This doc offers great depth on why dynamic shared objects are so hard: https://software.intel.com/sites/default/files/m/a/1/e/dsoho... and that's just for Linux & co. I'm surprised the Go team chose to add support for DSOs.

Re: Building a Better Go Linker

#70

Post by ckok »

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…

Curious enough; we're working on just that, a commercial compiler and ide for Go. A go compiler that can compile for .NET, native Windows, native Linux and native OSX. Haven't done much performance analysis yet, the IDE and and compiler are a first priority now, and are almost done.
Post reply on HN