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

The title is misleading

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.

Why should it be one?

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.

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.

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

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?

Yes, there is some information that is written by the linker in the final data section of the binary, the itab, that is the interface table for the dynamic dispatching. AFAIK, it is done there because you need to know other packages structs and interfaces to have the whole picture and build that table, and that happens using the build cache.

yes, the interface tables! that was the word I didn't remember. and that is some computation going on there not "just" merging sections, and, in a normal static linker, wiring exports to imports, and not pulling in unneeded definitions (dead code elimination).

the interface table computation is a golang speciality, a fascinating one.

and the implementation of interface magic is disturbingly not mentioned in the article.