Here's my personal experience. Simple go code is actually comparable to c, even for non-io bound tasks. I was very surprised when OpenSSL's AES implementation and go's AES implementations performed similarly in my microbenchmarks. The jvm actually performs very well (go figure that over a decade of optmization in running enterprise workloads would result in a fast runtime). I've inspected the generated assembly in a go code and compared it with that from the equivalent c code and there's no doubt go isn't the most efficient language ever created.
Use go if you want something that's (pretty darn) fast, productive, and has a standard library written by some of the most respected names in the field. Don't use go if you need the most mature and performant runtime and libraries. I have no doubt that they will get there eventually.
Not to mention it used an ancient version of Go, even Go 1 is dramatically faster than that, and since Go 1 there have been even more dramatic performance improvements, but the main issue is that the guy that wrote the benchmarks really had no idea what he was doing (there were similar criticisms from outside the Go communities about the quality of the benchmark).
Honestly I'm happy to hear that. I'm one of those rare individuals who gets to write go at work. I'm really happy with go performance and memory usage. Like really really happy. The different between the cpu usage of a go program using protocol buffers and a python program using protocol buffers is pretty dramatic (go is the clear winner).
Most folks would assume a paper coming out of google involving go has some go experts involved. Clearly this is not the case.
Comments
No surprises here. Google did a benchmark on go, java, scala, and c++ that's worth reading. http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-p...
Here's my personal experience. Simple go code is actually comparable to c, even for non-io bound tasks. I was very surprised when OpenSSL's AES implementation and go's AES implementations performed similarly in my microbenchmarks. The jvm actually performs very well (go figure that over a decade of optmization in running enterprise workloads would result in a fast runtime). I've inspected the generated assembly in a go code and compared it with that from the equivalent c code and there's no doubt go isn't the most efficient language ever created.
Use go if you want something that's (pretty darn) fast, productive, and has a standard library written by some of the most respected names in the field. Don't use go if you need the most mature and performant runtime and libraries. I have no doubt that they will get there eventually.
> No surprises here. Google did a benchmark on go, java, scala, and c++ that's worth reading.
No, is not worth reading, is misleading at best and has been throughly debunked:
http://blog.golang.org/2011/06/profiling-go-programs.html
Not to mention it used an ancient version of Go, even Go 1 is dramatically faster than that, and since Go 1 there have been even more dramatic performance improvements, but the main issue is that the guy that wrote the benchmarks really had no idea what he was doing (there were similar criticisms from outside the Go communities about the quality of the benchmark).
Honestly I'm happy to hear that. I'm one of those rare individuals who gets to write go at work. I'm really happy with go performance and memory usage. Like really really happy. The different between the cpu usage of a go program using protocol buffers and a python program using protocol buffers is pretty dramatic (go is the clear winner).
Most folks would assume a paper coming out of google involving go has some go experts involved. Clearly this is not the case.
Wow, thanks for sharing.
Every time I read something from Russ Cox he impresses me a bit more. That guy is amazing.