Understanding the Go Compiler: The Linker

This is entirely tangential to the article, but I’ve been coding in golang now going on 5 years.

For four of those years, I was a reluctant user. In the last year I’ve grown to love golang for backend web work.

I find it to be one of the most bulletproof languages for agentic coding. I have a two main hypotheses as to why:

- very solid corpus of well-written code for training data. Compare this to vanilla js or php - I find agents do a very poor job with both of these due to what I suspect is poorly written code that it’s been trained on. - extremely self documenting, due to structs giving agents really solid context on what the shape of the data is

In any file an agent is making edits in, it has all the context it needs in the file, and it has training data that shows how to edit it with great best practices.

My main gripe with go used to be that it was overly verbose, but now I actually find that to be a benefit as it greatly helps agents. Would recommend trying it out for your next project if you haven’t given it a spin.

Perfectly happy with Go, my "Go should do X" / "Go should have Y" days are over.

But if I could have a little wish, "cargo check" would be it.

I always have the unfounded feeling that the go compiler/linker does not remove dead code. Go binaries have large minimal size. Tinygo in contrast can make awesome small binaries

It's always fascinating to dive into the internals of the Go linker. One aspect I've found particularly clever is how it handles static linking by default, bundling everything into a single binary

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

Why not skip linker at all and generate single optimized exe file?

I'm impressed with how approachable the explanation is!