Yes, the other guys are just being pedantic because libc is attempted loaded dynamically (but it is not required—DNS behaviour just may change without it).

> Aren't go programs statically linked?

Not by default. You have to set CGO_ENABLED=0 to statically link libc.

Well, Go code is statically linked, but the runtime may try to dynamically load libc for DNS resolving. Use of cgo of course drastically change everything.

By default, nowadays the toolchain also supports generating dynamic libraries.

And by default, this feature is not used.

So what, it doesn't make this "Go code is statically linked" into a fact, given that it depends on compiler flags.

Now if it said "Go code is usually/by default statically linked", then yes.

Do native Go programs use libc?

For a few things like system DNS resolver in net package (can be switched to the pure Go version with compile-time or run-time switch) and getting user's home directory in os/user package.

To expand on this:

    $ cat foo.go 
    package main
    
    import (
     	"fmt"
    )
    
    func main() {
    	fmt.Println("Hello")
    }
    $ go build foo.go
    $ file foo
    foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

compared to:

    $ cat bar.go
    package main
    
    import (
    	"os/user"
    	"fmt"
    )
    
    func main() {
    	u, err := user.Current()
    	fmt.Println(u, err)
    }
    $ go build bar.go
    $ file bar
    bar: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

You can usually build fully static by doing

    CGO_ENABLED=0 go build

even when using os/user or net/

At a computer with go1.4.2 freebsd/amd64 ATM (earlier was go1.8.1 linux/amd64 IIRC) and the above os/user example results in a dynamically linked ELF when built with CGO_ENABLED set to 0.

I am pretty sure they don't.

Nope.

Runtime has changed too... slightly