10 ms·

> 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,

> 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=all&lang=go&lang2=java 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 14y ago
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.
- soc88 14y ago
  > The graphs on that page show Go beating Java in memory usage in every case. "Beating"? The JVM is configured to take as much available memory it thinks is necessary to speed up execution. Go lacks pretty much any runtime optimization and therefore doesn't do that. > 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). That's just non-sense. You take some (actually discouraged) corner cases of a completely different language to arrive at the decision to roll your own runtime (something the team seems to be completely unqualified for, judging the current state of the GC in Go?). > My observation of similar Go programs is that these kinds of problems don't really come up. Yes, because no one actually uses Go for anything where GC or latency would actually matter. Not even the garbage collection is working properly today. Please, show me some Go application server running with 128 GB heap doing something useful. I don't think Go (or Dart) will have any mid- or long-term impact. The "OMG, we're at Google, we're so brilliant, let's design a language for all those stupid non-Google losers out there" approach to language design isn't working out so well, it seems. Not even mentioning how seriously they messed up their "error" checking design. Confusing product with sum types ... god, you can't make that up.

enneff 14y ago

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.

soc88 14y ago
> The graphs on that page show Go beating Java in memory usage in every case. "Beating"? The JVM is configured to take as much available memory it thinks is necessary to speed up execution. Go lacks pretty much any runtime optimization and therefore doesn't do that. > 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). That's just non-sense. You take some (actually discouraged) corner cases of a completely different language to arrive at the decision to roll your own runtime (something the team seems to be completely unqualified for, judging the current state of the GC in Go?). > My observation of similar Go programs is that these kinds of problems don't really come up. Yes, because no one actually uses Go for anything where GC or latency would actually matter. Not even the garbage collection is working properly today. Please, show me some Go application server running with 128 GB heap doing something useful. I don't think Go (or Dart) will have any mid- or long-term impact. The "OMG, we're at Google, we're so brilliant, let's design a language for all those stupid non-Google losers out there" approach to language design isn't working out so well, it seems. Not even mentioning how seriously they messed up their "error" checking design. Confusing product with sum types ... god, you can't make that up.