[anonacct37]

I do like this about go. And on Linux it arguably makes sense (I say arguable because DNS without CGO is still a common cause of issues and incompatibility).

But Linux has, to the best of my understanding said "yes, we are ok with users using syscalls". Linux doesn't think that glibc is the only project allowed to interface with the kernel.

But for other platforms like OpenBSD and windows they are quite simply relying on implementation details that the vendors consider to be a private and unsupported interface.

This whole thing is also separate from "is making libc the only caller of the syscalls instruction" a good and meaningful security improvement.

[akira2501]

> I say arguable because DNS without CGO is still a common cause of issues and incompatibility

DNS without CGO works perfectly. The vendor specific ad hoc mechanisms for extending DNS in a site local context are not well supported. If they were implemented more sensibly, then Go, or any other language, would have no problem taking advantage of them even without the "C Library Resolver."

Speaking of which, that "C Library Resolver," in my opinion, has one of the worst library interfaces in all of unix. It's not at all a hill worth new projects dying on.

[ninkendo]

> The vendor specific ad hoc mechanisms for extending DNS in a site local context are not well supported

DNS is one of those things that OS vendors think should be extendable and configurable. It allows VPN apps to redirect DNS only for certain subdomains, for example, which enables proper split-horizon DNS. I think this is totally reasonable behavior, and it’s undeniably useful. If a particular programming language reimplements DNS on its own, you lose guarantees that the OS is striving to provide to the user.

You can make the case that OS’s shouldn’t make these guarantees, and we’re free to disagree on that, but from a practical standpoint it is a very useful feature and it sucks that pure Go apps don’t work with it.

[anonacct37]

> DNS without CGO works perfectly

It does not. I know this because it impacts my daily work and the work of others. Honestly if you could make my day and go figure out exactly what's going wrong with the pure go DNS implementation it would make my life alot simpler and I wouldn't have to maintain shell scripts that update etc/hosts to hard code in ipv4 addresses for the APIs I access with terraform.

https://github.com/hashicorp/terraform-provider-google/issue...

[toast0]

Most unixes allow for static binaries. And most unixes allow for you to run a static binary compiled for an older OS on a newer OS. In order for that to work, the syscall interface needs to be at least mostly stable.

Yes, if you're writing netstat or lsof or ps or something, you need tight coupling with the binary and the kernel, and you can argue Linux does that better, but most people aren't writing netstat or lsof or ps.

[IAmLiterallyAB]

Even those get most of their info from /proc and /sys rather than special syscalls

[p_l]

Windows also provides language-independent ways of calling low-level (and pretty high-level) OS interfaces.

The library you have to link to access system services is not going to pollute your language environment with bad runtime.

[Varriount]

Does Go use direct syscalls on Windows? Last time I looked, I could have sworn Go's source used the standard Windows system DLLs.

[pjmlp]

On Windows it never did, and on other platforms, other than Linux, it has been forced to accept that isn't the way OS vendors play the game.