>Its within spitting distance of C/C++ code for performance and will improve. No, it is not. I don't want to make too much of this because I know that these so

>Its within spitting distance of C/C++ code for performance and will improve. No, it is not. I don't want to make too much of this because I know that these sort of performance characteristics seldom matter at all in the kind of programming most of us would do with Go, but - - based on the benchmarks game (http://shootout.alioth.debian.org/u32/which-programs-are-fastest.php http://shootout.alioth.debian.org/u32/which-programs-are-fas...) - Go is 6x slower than Fortran/C and is quite a lot slower than Java as well. The 6g/8g compilers will never be nearly that fast because they are optimized for compile time rather than runtime. gccgo may eventually be nearly that fast. Go will never be a systems language because it will never be possible to: * control memory directly (kernel, device drivers) * expose a C compatible binary interface (libraries) * dynamically link to libraries (pluggable modules ala Apache httpd) That rules out a whole heck of a lot of software that could reasonably be considered systems work. Of those issues, by far the lack of an ABI is the biggest turn-off to me. I would really like to be able to optimize critical Ruby code by writing native extensions in Go rather than C, but I can't and never will be able to. Rust is really the only thing that may someday be a more reasonable choice for that than C. Instead what has happened is a lot of Python and Ruby developers have picked up Go and would like to call their work "systems programming". Go is pretty good for a lot of this work, but it is not systems work.