Yeah the linked issue (16570) is the most interesting one, with the Go runtime breaking multiple times in the runup to Sierra as Apple changed the ABI of the underlying gettimeofday syscall.

Wow, that seems like a really bad approach for Go to take. So is anybody actually using Go on OS X? I guess maybe not, if all the real Go deployments are on servers running Linux.

I do a bunch of development work using Go on OSX but I do deploy the resulting solutions on Linux.

Aha, that's kind of what I'd figured. Work on Mac, deploy on Linux.

It makes me think twice about e.g. using Go as part of the build workflow in a big project if it's going to randomly stop working on various OS X versions.

>"golang also targets syscalls instead of the C standard library"

What would have been the reasons for targeting syscalls directly instead of the C standard library?

> What would have been the reasons for targeting syscalls directly instead of the C standard library?

Since the standard library probably assumes (and requires) a C stack, linking against the standard library would require cgo (or some other specific workaround) on non-linux platforms.

I'm guessing it has to do with the fact that you can build go binaries not linked with libc, they also expose syscall.RawSyscall anyway that all the other syscall wrappers call out to last time I looked

Interesting, thanks for linking that.