3 ms·
Build times are fantastic. Performance is still quite a bit worse than Java, actually. It has its own compiler, and so it doesn't benefit from the huge amount o
by lobster_johnson 13y ago
Build times are fantastic. Performance is still quite a bit worse than Java, actually. It has its own compiler, and so it doesn't benefit from the huge amount of work put into optimization in GCC and LLVM. Definitely not roses and unicorns.
- burntsushi 13y agoWhat is "quite a bit worse"? Is that 2-3x slower? Or 20-30x slower? It's my understanding that it's the former. And then there's memory consumption...
- lobster_johnson 13y agoThe former.
- MetaCosm 13y agoGo has MULTIPLE compilers, because Go is a language spec, not a compiler. Hence GCCGO (which for example, takes advantage of some of those GCC optimizations) can be used. Additionally, in most benchmarks, Go does fairly well and is young and constantly improving: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ You will also find Nimrod / Jester in those benchmarks, and can compare the performance for yourself.
- lobster_johnson 13y agoPedantry. When people talk about Go, they usually mean the official implementation. gccgo has too many issues (lags behind release, requires gcc recompile, etc.) to be useful to most people.
- MetaCosm 13y agoI disagree. I know most Go shops I have dealt with at least have looked into gccgo. We use gccgo in the wild (for all our image processing components), because it gave us a nice performance boost. With good testing, you can easily do A/B testing using gccgo to see where it makes sense for you in production. We have to dig through 30TB of images -- so the performance benefits we got from gccgo were worth the trivial effort it took to implement.