[enneff]

Go lets you pass around raw values without overhead. An int32 is 4 bytes. A struct { a, b int32 } is eight bytes. A [4]int32 is 16 bytes. A [4]struct{ a, b int32 } is 32 bytes. (I think you get the point :-)

In Java all objects are passed by reference, which causes bloat and cache locality issues. Also there are bookkeeping costs associated with even trivial objects: a simple array carries around an additional 16 bytes of memory.

Furthermore, the core Java libraries make it very difficult to write code that doesn't generate a lot of garbage. In fact, it's very difficult to write allocation-efficient code in Java without writing very unidiomatic Java code. These problems are worsened in more dynamic JVM-based languages like Scala and Clojure, which generate huge amounts of garbage due to runtime reflection.

Here's an interesting discussion of these issues:

http://loadcode.blogspot.com/2009/12/go-vs-java.html

[rabbitfang]

> dynamic JVM-based languages like Scala and Clojure

Scala is a statically typed language

Go may make more efficient use of memory for the cases you describe, but the JVM still beats the pants off Go:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Also, you haven't factored in Java's escape analysis and on-stack allocation.

[enneff]

The topic of this discussion is garbage collection and memory allocation. The graphs on that page show Go beating Java in memory usage in every case. I'm not sure what your point is.

Scala is a statically typed language but it must do runtime type reflection to implement some of its features on top of the JVM. That comes at a cost (and in fact we decided not to implement Go on the JVM for this exact reason). I know of a certain well-known company that uses Scala heavily and their JVM instances spend >80% of their CPU time in garbage collection.

The JVM has had a tonne of optimization done to it. The Go compilers and runtime have had barely any. There's plenty of low-hanging fruit: recent changes to the gc code generation have yielded as much as 2x speedups in certain operations.

My observation, from watching very skilled Java programmers build and deploy programs, is that garbage generation and collection latency cause serious problems. My observation of similar Go programs is that these kinds of problems don't really come up.

[azakai]

> Go lets you pass around raw values without overhead.

Does that rely on heuristics like escape analysis or is it user defined (and predictable)?