Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from.

The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc.

See https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.

It's not quite that simple unfortunately. If you build a Go package with CGO enabled then Go builds the binary dynamically linked to the system libc. (this can be especially surprising if you believe go is "statically linked") However when CGO is disabled it doesn't link against libc at all as Go has it's own syscall layer etc.

It's not clear what this new -static flag will do, likely automatically setup some of the linker static flags when compiling with CGO to statically link other dependencies and perhaps libc itself.

> It's not quite that simple unfortunately.

This has been my experience with Go. First a promise of everything being much simpler than the alternatives. Then, when we run into all sorts of confusion and caveats, an unapologetic disclaimer about why it's not simple and can't be, with a long exposition about Go's own internal limitations and the trade-offs they had to make.

From my experience Go is simpler than other langs where it can be, and at worst equally 'difficult' than the others. On average it's simpler.

Go can link against c libraries. This would make that static as well.