Hector Martin

Go tried to hardcode syscalls on macOS anyway. Then they broke the gettimeofday interface and all Go apps exploded. The other issue is that Go's C FFI is slow (and buggy and convoluted), and they have to use it for syscalls on those platforms, with worse results.

So Go *does* dynamically link with C libs in the end on those platforms, but that entire feature sucks.

aaaahahaha

I also wonder how they handle like, 3D graphics. I guess it's not something people use Go for, but if they want to, sorry… you need dynamic linking. You can't statically link the graphics driver, unless perhaps you really love Mesa

I mean, they do claim to support dynamic linking C libs. People use it. I've used it. It sucks.

The first time I tried using Go I ran into a FFI bug which took 2 days to find and fix (after the Go devs had been unable to figure it out for months) and then a month of bureaucracy to get merged. I didn't write any more Go after that (and after seeing the guts of the runtime).

Then I still had to find and debug *another* Go runtime bug after unfortunately running into random segfaults in a piece of software I used that was written in go. The root cause turned out to be Go devs knowingly making invalid ABI assumptions **to avoid using their slow FFI**.

Because on Linux... surprise! gettimeofday is not a syscall if you want to be fast, it's a call into vDSO, which is just a C ABI call into a special dynamic library that the kernel stuffs into your address space... But actually using Go's C FFI for that would kill the perf.