Re: [dev] Suckless remote shell?

From: Szabolcs Nagy <nsz_AT_port70.net>
Date: Mon, 4 Nov 2013 21:54:23 +0100

* Bobby Powers <bobbypowers_AT_gmail.com> [2013-11-04 13:10:56 -0500]:
> 2013/11/4 Szabolcs Nagy <nsz_AT_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)
Received on Mon Nov 04 2013 - 21:54:23 CET