[Surac]

I can see no difference to an ordinary linker. Anyone care to explain it to me.?

[jespino]

Yes, it is not specially different from other linkers. It has some tasks building the final binary including special sections in the binary, and is more aware about the specifics of the go language. But there is nothing that is extremely different from other linkers. The whole point of the series is to explain a real compiler, but in general, most of the parts of the go compiler are very widely used in other languages, like ssa, ast, escape analysis, inlining...

[froh]

when does golang create the final dynamic dispatch tables? isn't that the one thing that in golang needs real compute at final link time, beyond what a C linker would do? and where C++ has all information at compile time, while golang can only create the dispatch tables at link time?

[gregwebs]

The difference is that Go has its own linker rather than using a system linker. Another article could explain the benefits of tighter integration and the drawbacks of this approach. Having its own toolchain I assume is part of what enables the easy cross compilation of Go.

[jrockway]

You can actually make go spit out .o files and link it with your favorite linker. Bazel does this, if you ask it to.

I played a lot with experimental linkers when I was trying to get build time down for our (well, $JOB-1's) large Go binary, but they didn't help that much. The toolchain that comes with Go is quite good.

[jenoer]

What is there to explain? The author did not claim there is a difference in the article.

[pjmlp]

Why should it be one?

[cloudhead]

The title is misleading

[jespino]

Misleading in what way? This is the linker part of a serie of posts about understanding the go compiler. I think there is no much space to be misleading.