* Alexander S. <alex0pla...@gmail.com> [2013-11-04 17:11:40 +0300]: > 2013/11/4 FRIGN <d...@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
