2013/11/4 Szabolcs Nagy <n...@port70.net>: > the state-of-the-artedness is not a virtue of a programming language
Agreed. At the same time, I don't think 'it is not C' should be an automatic point against a language. C is excellent and quite useful, however Go's language is wonderfully simple and makes expressing certain things quite clear an succinct. > 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 It was written by the people behind plan 9. It is somewhat of an appeal to authority, but I tend to give the Go authors the benefit of the doubt when it comes to the unix legacy. > 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. > 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) True, I did not mean to imply it should be used from C, just that it is the only sane SSH implementation I've personally looked at. > 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? yours, Bobby
