Another worry I have is the 'backwards compatibility'. It sounds good but in the long run creates its own problems. I think Java and even Python run into major problems with this.
If you actually follow the links, you will see they are reimplementations of the algorithms in assembly.
GCC doesn't have any crypto code, fast or otherwise. Crypto algorithms routinely get dramatic speedups when going from C to hand-coded assembly, C compilers produce code that is far from optimal. See eg. http://cr.yp.to/aes-speed.html
> Another worry I have is the 'backwards compatibility'. It sounds good
> but in the long run creates its own problems. I think Java and even
> Python run into major problems with this.
And the compiler support is not yet mature. GDC has missed inclusion into GCC 4.8, while Go went into GCC 4.7, which makes using Go possible on a number of platforms and configurations.
http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
Not surprising though, as GCC's optimization backend is very strong and has been developed for a long time, meanwhile Go's compiler toolchain is very young.
As for Scala vs Go, Scala compiles into Java bytecode and then makes use of Java's excellent and very mature JIT compiler so I'm not surprised Go loses out to it for the same reasons mentioned above.
Also note that the Go version used on the 'Language Shootout' is the 1.03 version, not the upcoming 1.1 version, it will be interesting to see what improvements in performance have been made.
AFAIK the 32-bit version of Go (which is what you compared with in your link) has not been given as much love in the optimization department as the 64-bit version, which I guess would do slightly better atleast.
Without knowing it's name :-)
Is there a point to you continuing to spin on this???
If you have something specific to say, say it.
The reason the code quality (in optimization terms) of Go's compiler isn't that great is that the Plan 9 C compiler was always designed for fast compiles. This is a matter of design.
By comparison, LLVM/GCC passes code through multiple internal representations and performs many complex optimizations on them before emitting assembly.
The link you provided doesn't point to anything called that.
On another note, your threads about the name change are adding little value to the conversation. Perhaps the time could be better spent? You are sort of wasting people's time. Next time, maybe simply say that the "Language Shootout" has been changed to the "Benchmark Game?"
It's important as an indicator of how much or how little you noticed when you looked at those web pages.
The other ways people don't see what actually is shown are more difficult -- taking memory use and code size measurements out-of-context.
Why would you expect that? The JVM has years worth of advanced optimizations.
Maybe once 1.1 is out and the language game switches to it, that will be the case (the benchmark is using the current stable release of Go 1.0.3).
Also, I assume you are talking about execution time, Go destroys Scala in your linked comparison in terms of memory usage.
One note, Scala uses more memory than Java does, so it appears not all of this usage can be blamed on the JVM itself: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
Do you really think the JVM memory-use should be optimised for 100 line toy programs?
Static typing arguably makes it easier to provide a deeper and more accurate translation, but Python did at least try. And note that's a link to Python's official docs, not a side project or something; 2to3 was created by the core Python team as part of the official upgrade path, not an afterthought.
For whom? Five years is long enough to realize that you might as well try new languages instead of porting all your code base (and maybe some libraries that you need) to the slightly improved but backwards incompatible version of Python.