* Alexander S. <alex0player_AT_gmail.com> [2013-11-04 17:11:40 +0300]:
> 2013/11/4 FRIGN <dev_AT_frign.de>:
> >
> > No one ever said it, because it is expected to be in C.
> > Go is a disgrace and I'm glad every time I see a Go-Project bit-rot to
> > death.
> >
> Don't want to start a flame, but C isn't exactly state of the art
> language. I shall agree that Go has problems, but why it would be a
> disgrace any worse than a living fossil C is?
the state-of-the-artedness is not a virtue of a programming language
the main problem with go is that (like java and many other high level
languages) it tries to ignore unix legacy while building on it
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)
the consequence is that you cannot use go libraries from c code and using
c libraries from go code is a hack (relies on internal libc api behaviour
and currently on linux it only works with glibc) because the go runtime
cannot work with the c runtime in the same process
so the go ssh package is not useful for programs written in c (they can
only use it through some ipc mechanism, not in the same process)
as you can see the problem is not related to the modernity of the
language, but to the interoperability with the existing ecosystem
self-contained tools can be written in go (those can be developed in
any language) but if you want to share code with other projects you
have a problem
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
Received on Mon Nov 04 2013 - 17:11:54 CET