Is there an official documented rationale for why the Go standard library doesn't go use libc, and instead does all this direct syscall stuff?
I've heard various stories about it over the years, so i would appreciate an authoritative source.
I've heard various stories about it over the years, so i would appreciate an authoritative source.
I don't have an authoritative source, but I think one of the big downsides of CGO for them is that it hurts their cross-compilation story. Cross-compiling a pure Go program is trivial, which is great, but by default it disables CGO.
The authors want a world where you can just make a read syscall without using FFI.
It's possible this is a unrealistic expectation. Linux kernel interfaces are generally quite stable. On OSX and windows the kernel interface seems to be an undocumented unsupported API which is sad.
why the Go standard library doesn't go use libc
The parent post does explain, about as well as any member of the go-team has to date for their usage of `musl-libc` over `gnu-libc` (glibc). Overall `musl-libc` does focus on correctness a lot more then `glibc`, and static linking is a large benefit.
Static linking isn't an issue when you expect applications to be short lived transient items. Where system images only exist for days, or hours before being redeployed by either patches, or CI-Managered triggered updates. I think this is the largest disconnect. Go expects the development pipeline to be quick so nobody expects multi-year lifespan binaries, which is directly contradictory to how many expect executable binaries to behave.
No that I'm authority on this, just stating a common disconnect I've experienced working with ex-Googlers.
[1] https://www.musl-libc.org/
[2] https://www.gnu.org/software/libc/
[3] https://wiki.musl-libc.org/functional-differences-from-glibc...
No. Historically they don't use a libc at all if you don't use the DNS subsystem. The latest version (1.11) finally started using libSystem on OSX (where performing raw syscalls has never ever been supported, and Go broke several time because they refused to acknowledge that).
Are you running the build inside a docker container which uses musl, such as alpine?
Those are the cases where this might happen.
On a normal linux distro, this will not happen.
They only default to the system's libc (which is typically gnu libc, though could be musl) if certain networking constructs are used. They otherwise default to not using any external libc library, but rather implementing one with syscalls internally.
The above is for linux. On other platforms it varies further, but to my knowledge the parent post is not right on any platform.