> It is very common for language runtimes to link and depend on libc on Unix
It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it.
> MacOS doesn't guarantee backward compatibility for direct syscalls.
Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it.
But if we're talking about Linux libc, there's no reason for Go to use it.
> POSIX is defined in terms of a C standard library
Specifically POSIX.1 (not POSIX.2).
Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.
It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.
It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it.
> MacOS doesn't guarantee backward compatibility for direct syscalls.
Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it.
But if we're talking about Linux libc, there's no reason for Go to use it.
> POSIX is defined in terms of a C standard library
Specifically POSIX.1 (not POSIX.2).
Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.