undefined | Better HN

story

0 pointssteveklabnik1y ago0 comments

In my understanding, Go initially disregarded various platforms' rules here, and have ended up walking it back. I could be wrong though.

It's hard to find good details here, but here's a mailing list thread from 2019 mentioning libc usage: https://groups.google.com/g/golang-nuts/c/uX8eUeyuuAY/m/Cfhl...

> On Solaris (and Windows), and more recently in macOS as well we link with libc (or equivalent).

> Go used to do raw system calls on macOS, and binaries were occasionally broken by kernel updates. Now Go uses libc on macOS.

0 comments

PaulDavisThe1st1y ago

Yep, in 2022 it finally started using libc on *BSD too.

But ... there's a difference between being able to do direct syscalls via asm, and them being portable across kernel versions, which is what this subthread was about.

Granted, most people want version portability, but still on a technical level, it's not the same thing.

steveklabnikOP1y ago

No, my comment was about what APIs a platform considers to be their stable, external API. That you can technically call them anyway (except for ones like OpenBSD that actively check and prevent you) doesn't mean you're not doing something unsupported.

j / k navigate · click thread line to collapse