3 ms·

The problem here is that the choice is one extreme or the other, never the happy medium. The extremes are statically linked everything and dynamically linked e

by JdeBP 10y ago

The problem here is that the choice is one extreme or the other, never the happy medium. The extremes are statically linked everything and dynamically linked everything. Bryan Cantrill deplores this part of the design of Go. He decries the fact that rather than sitting on top of a HLL-function-call binary interface, with the portability layer being HLL function calls like read(), write(), close(), socket(), execve(), Go produces executables that hardwire one specific instruction set's kernel system call traps. See https://news.ycombinator.com/item?id=11392119 https://news.ycombinator.com/item?id=11392119 for his own words. GCC allows one to selectively statically link various libraries in an otherwise dynamically linked executable. (clang had yet to achieve this functionality, last that I checked a year or so ago.)

justin66 10y ago
Bryan would have to elaborate an awful lot on the evilness of using system calls to make that a more general argument. (we're not supposed to use the kernel now for some reason?) It looks like it was just kind of a pain in the ass for the Joyent guys because of what they were doing specifically, which was pretty specialized. (there's a mean and almost clinically insane blog post about Go by one of the other Joyent guys, who retired a week or two after writing it, which also doesn't shed much light but is funnier. You've got to wonder what their deal is with the Go guys, exactly...)
- 4ad 10y ago
  Yeah, on Linux, the system call interface is the supported interface for interacting with the kernel. Of course we are going to use it since 1) it's supported, 2) it's stable, more stable than e.g. glibc has ever been, not to mention we're not locked to a particular libc vendor, it just works on embedded systems which don't use glibc, 3) it allows us to make system calls without going through all the cgo machinery and without having to switch stacks. On Solaris, the system call interface is not a supported public interface, so I made the Solaris port use libc through cgo. Solaris made the decision that the supported public interface is through libc. That's a fine decision to make if you are the sole vendor of libc. But, that doesn't mean there's anything wrong with different operating systems making different decisions. On Linux we use the Linux rules, and on Solaris we use the Solaris rules. I will tell you this though, having done numerous Go ports and having written many Go compiler targets several times, it's much, much simpler to port Go if your target is something that allows static executables and making system calls. Having done linux/arm64 and solaris/sparc64, I know exactly how much harder is one versus the other.
  - justin66 10y ago
    > On Solaris, the system call interface is not a supported public interface To be honest, I did not know that, I guess it's never been an issue for me. That sheds a little light. Thanks.

by JdeBP 10y ago

justin66 10y ago

Bryan would have to elaborate an awful lot on the evilness of using system calls to make that a more general argument. (we're not supposed to use the kernel now for some reason?) It looks like it was just kind of a pain in the ass for the Joyent guys because of what they were doing specifically, which was pretty specialized. (there's a mean and almost clinically insane blog post about Go by one of the other Joyent guys, who retired a week or two after writing it, which also doesn't shed much light but is funnier. You've got to wonder what their deal is with the Go guys, exactly...)

4ad 10y ago
Yeah, on Linux, the system call interface is the supported interface for interacting with the kernel. Of course we are going to use it since 1) it's supported, 2) it's stable, more stable than e.g. glibc has ever been, not to mention we're not locked to a particular libc vendor, it just works on embedded systems which don't use glibc, 3) it allows us to make system calls without going through all the cgo machinery and without having to switch stacks. On Solaris, the system call interface is not a supported public interface, so I made the Solaris port use libc through cgo. Solaris made the decision that the supported public interface is through libc. That's a fine decision to make if you are the sole vendor of libc. But, that doesn't mean there's anything wrong with different operating systems making different decisions. On Linux we use the Linux rules, and on Solaris we use the Solaris rules. I will tell you this though, having done numerous Go ports and having written many Go compiler targets several times, it's much, much simpler to port Go if your target is something that allows static executables and making system calls. Having done linux/arm64 and solaris/sparc64, I know exactly how much harder is one versus the other.
- justin66 10y ago
  > On Solaris, the system call interface is not a supported public interface To be honest, I did not know that, I guess it's never been an issue for me. That sheds a little light. Thanks.