【发布时间】：2018-03-21 07:43:44
【问题描述】：
Go 将所有 syscall-s 包装在包 syscall 中，就像我理解正确时 libc 所做的一样。
我研究了几种语言，
Haskell，在编译器中使用 libc，库通常也使用它，尽管有一些库为用户包装系统调用。
Java 和几乎所有 JVM 语言都选择 libc。
脚本语言就不用说了，比如lua、ruby或python，它们需要可移植，所以需要libc作为POSIX的实现。
最近没用rust，不过也有人说rust也是用libc的。
那么，为什么 golang 决定首先实现一个 syscall 包。它不可移植，移植到每个内核甚至同一内核的每个主要版本都需要花费更多的人。
【问题讨论】：
-
这只是一个猜测，但golang的一大卖点是它可以轻松进行静态构建，并且可以构建不依赖libc的执行二进制文件，所以他们可能决定不依赖libc。
-
除了易于进行静态构建之外，还有一点是 Go 使用不同的调用约定，与 C 不兼容。直接实现系统调用可以节省大量开销。
-
这是 Go 团队的问题，而不是 StackOverflow。试试 Go 邮件列表。
标签： go system-calls libc