3 ms·

> Go devs, saying that it was technically impractical due to some of Go's requirements not matching the libc's semantics. I've always considered claims like th

> Go devs, saying that it was technically impractical due to some of Go's requirements not matching the libc's semantics. I've always considered claims like this to be bullshit. I've worked a lot with both libc level system calls and (for crash report generation) direct system calls bypassing libc. They're the same interface. There's nothing you can do with a raw system call interface that you can't do through raw libc --- with rare exceptions for things like libc not having system call wrappers for some new system call or legacy ill-advised emulation like in fallocate. None of these exceptions is a justification for bypassing libc for calling open(2) or write(2). As far as I can tell, the real reason Go eschewed libc system call interfaces is that the Go developers want to think of themselves as "not C".

ominous_prime 6y ago
Go has a different calling convention and stack layout from C, and wanted completely static binaries which you cannot always get when linking to the standard libc implementations. What is "bullshit" about these compatibility concerns? It's not like _Ken Thompson_ was unaware of how to use libc.
- quotemstr 6y ago
  Yet Go can call libc functions just fine on many OSes. Why can't it on Linux? Every single other managed runtime --- Mono, Java, Python --- can call through libc just fine. There is zero technical case for Go not doing the same thing. The bullshit lies in these FUDlike insinuations that using libc would limit Go in some way. These insinuations are never backed up with technical specifics. I don't care that famous names are involved with Go: the presence of these people doesn't make Go's behavior correct or necessary. There is zero technical case for Go doing what it does on Linux. You can make a "fully static binary" (which is a terrible idea anyway) with libc. Nobody should be making static binaries.
- int_19h 6y ago
  There are many languages and runtimes that use their own calling conventions - not the least of which is C++ - and even stack layouts. The problem with Go is specifically the spaghetti stack that they need for coroutines. But that is an inherent design issue - a systems programming language is supposed to play well with the system, and that means being able to use the standard OS APIs properly. Which on basically all platforms other than Linux means going via libc or equivalent (e.g. Win32). Go designers just unilaterally decided that the rules don't apply to them, because reasons. And the end result was stuff like this: https://github.com/golang/go/issues/16606 https://github.com/golang/go/issues/16606 So now they're gradually backtracking on all platforms - macOS switched to libc a while ago.
bborud 6y ago
Those sound like assumptions. Can you back it up with examples of what cases Go developers saw as problematic and point out what they should have done instead (and that this indeed does not represent a problem)?

ominous_prime 6y ago

Go has a different calling convention and stack layout from C, and wanted completely static binaries which you cannot always get when linking to the standard libc implementations. What is "bullshit" about these compatibility concerns? It's not like _Ken Thompson_ was unaware of how to use libc.

quotemstr 6y ago
Yet Go can call libc functions just fine on many OSes. Why can't it on Linux? Every single other managed runtime --- Mono, Java, Python --- can call through libc just fine. There is zero technical case for Go not doing the same thing. The bullshit lies in these FUDlike insinuations that using libc would limit Go in some way. These insinuations are never backed up with technical specifics. I don't care that famous names are involved with Go: the presence of these people doesn't make Go's behavior correct or necessary. There is zero technical case for Go doing what it does on Linux. You can make a "fully static binary" (which is a terrible idea anyway) with libc. Nobody should be making static binaries.
int_19h 6y ago
There are many languages and runtimes that use their own calling conventions - not the least of which is C++ - and even stack layouts. The problem with Go is specifically the spaghetti stack that they need for coroutines. But that is an inherent design issue - a systems programming language is supposed to play well with the system, and that means being able to use the standard OS APIs properly. Which on basically all platforms other than Linux means going via libc or equivalent (e.g. Win32). Go designers just unilaterally decided that the rules don't apply to them, because reasons. And the end result was stuff like this: https://github.com/golang/go/issues/16606 https://github.com/golang/go/issues/16606 So now they're gradually backtracking on all platforms - macOS switched to libc a while ago.

bborud 6y ago

Those sound like assumptions. Can you back it up with examples of what cases Go developers saw as problematic and point out what they should have done instead (and that this indeed does not represent a problem)?