为什么golang选择syscall而不是libc

Question

Go wraps all syscall-s in package syscall, just like what libc does if I understand them right.

I've researched a few languages,

• Haskell, using libc in compiler and the libraries normally use it too, although there is a few libraries wrapping syscall for users.

• Java and almost all JVM languages choosing libc.

No need mention script languages, such as lua, ruby or python, they need portable, so they need libc as an implementation of POSIX.

I didn't use rust recently, but there are some people just said rust using libc too.

So, why golang decided to implement a syscall package at first. It's not portable, cost more people to port to each kernel, even each major version of the same kernel.

Answer 1

Because Go manages its processes in goroutines managed by the Go Runtime which is written in C and statically linked to the compiled user code during the linking phase. Since go manages its syscall with its own runtime not directly in the OS, that is why it implemented its own syscall package.