* Bobby Powers <bobbypow...@gmail.com> [2013-11-04 13:10:56 -0500]: > 2013/11/4 Szabolcs Nagy <n...@port70.net>: > > go is special in that it builds on the binary syscall layer instead of > > the somewhat portable c api (the syscall layer is not even expected to > > be stable on every unix, openbsd just broke it to have 64bit time_t > > on 32bit systems, so go releases and existing go binaries are broken > > on the latest 32bit openbsd) > > As are all statically linked C binaries, Go isn't special here. > OpenBSD broke their ABI.
if the abi is not a public interface then any project depending on it should expect breakage, static c code can be recompiled and it will work (assuming portable c code) but it is not enough to recompile the go runtime, they have to update their syscall wrappers since go is not maintained together with the os they have to worry about different versions of the os vs different versions of the go runtime working together otherwise go programs and go programmers are in trouble on openbsd > > go cannot completely replace the c ecosystem in the unix userspace > > because of its runtime (gc etc) so we are left with yet another set > > of reimplementation of the world, a separate platform to maintain > > for eternity > > Why does the go runtime & GC mean that it cannot replace the C unix > userspace? Or are you saying that you see the runtime as > overcomplicated, so you do not wish unix userspace to be replaced with > a unix userspace written in Go? i don't mind if the c userspace is replaced with somehing else i just think it's hard to do and go cannot do it (note that go was never advertised as a c replacement, the authors wanted it for specific applications in mind: mostly large scale networked systems software running on servers i guess) avoiding dynamic allocations, working correctly even when the system runs out of memory, directly handling signals without userspace scheduling overhead, accessing the floating-point environment are all difficult or impossible in go and there is performance overhead inherent to the language (gc and scheduler are not in the application's control, interfaces require runtime type information, no inline asm means arch specific code has func call overhead, etc) these are relevant to some applications and libraries it is also a lot of work to rewrite everything (there are closed video drivers on linux linked against glibc, lot of programming languages and tools depend on the behaviour of the c runtime which should be reinvented not just reimplemented, and getting a usable toolchain for every relevant architecture is difficult enough)
