[jaen]

Nah. Go also relies on libc if you do anything non-trivial, like look up a the IP address of localhost.

    $ go build -o hello main.go
    $ file hello && ldd hello
    hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go
        linux-vdso.so.1 (0x00007f9c7b404000)
        libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c7b1ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9c7b406000)

[cloudfudge]

Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS.

(full disclosure, I don't think I ever had my service look up the address of localhost)

edit: seems like you probably have CGO_ENABLED=1, which is now the default and will cause simple networking things to use libc. Set CGO_ENABLED=0 and you won't have libc.

[jaen]

Yeah, I'm fully aware, no point in "works for me"-ing this.

CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.

[cloudfudge]

> Only usable if you only care about your own system.

Ahaaa, that clicks. Yes, I tend to build software that only cares about my own systems.