Hacker News new | past | comments | ask | show | jobs | submit login

Call me a spoilsport, but it's still slower than Java http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... . That takes the bloom off the rose for me.



You're comparing Sun's Java 7, a mature mainstream, enterprisey language which has probably the compiler, virtual machine and GC most advanced in all of Computer Science's history, with a niche language that some Googlers hacked together. It would be too naive to expect Go to perform better than Java 7. However...

Notice that Go, compiled with the Plan 9 compilers, performs as well as Java in 7 of 11 tests and uses as much as 1/15 of its memory. All in all, not that bad.


Your also comparing a native compiled language with an interpreted language (albeit with a very good JIT compiler). At some point of maturity, I would expect the native language to edge out Java, and when you look at the benchmarks that is generally what you see.


Except for Haskell, OCaml, Pascal and SBCL Lisp. Java is faster than all of those (on the shootout micro benchmarks), and I'd say all of them are quite mature.

From what I can tell, on the Language Shootout, only C, C++ and Fortran beat Java.

N.B. I think I only looked at benchmarks for x64 quad core.


OCaml is instructive, that's another compiled-but-GC'd language. Looking at them they're about the same.

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...


True that it's slower, but the 'one core x86'-based benchmark comparison is the one it does worst in. And I doubt a one core x86 is hardly typical of what Go code will be running on.

Here are the results on a x64 quad: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Overall Go loses here aswell, but it does much better than in the comparison you linked, and like others have mentioned Go is still very young compared to Java.

Also, glancing at the tests where Go does really bad against Java they seem to be tests which rely much on runtime functionality, and the Java runtime/VM has had a very long time (+10 years?) in which to improve to it's current state.


Some might consider looking at more than just the time dimension though... Much more memory and more verbose code. I find that this adds up in real systems as there is less to tune for optimal performance and less code to audit.


Give it some time. It took a long time for Java and the JVM to be considered 'fast'.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: