3 ms·

Doesn't Go have a lower memory overhead than any JVM language?

oconnor663 7y ago
I don't know about the total memory overhead, but the Go team has written a lot about how their GC pauses are shorter.
webpaymentsguy 7y ago
I recently had to evaluate using Go vs Rust vs Java (current) and while Go did bring notable resource usage bonuses compared to JVM, Rust seemed to give significantly more if we did switch. The drawback of both Go and Rust for our group was that Java developers were so much more abundant in our market(not major technology hub city in the South). I think cities with smaller amounts of talent have the same problem when trying to find Go and Rust developers of all skill levels.
klodolph 7y ago
This is a reasonable question, so I’m unsure why it’s downvoted. It usually makes sense to talk about the memory overhead of the JVM itself, rather than talking about one of the languages specifically, like Java or Kotlin (but maybe Scala and Clojure are a bit different). The tradeoffs for GC systems are complicated and not easy to understand. Go supports only one GC system, as far as I know, which does not move memory and attempts to minimize GC pauses. It sacrifices throughput and CPU utilization to achieve this. The JVM can be tuned in many ways and there are a number of different options, from choosing different GC algorithms to different memory models. Most JVM algorithms will compact memory. Some are optimized for throughput and others are optimized for shorter pauses. In practice, my observation is that Go’s GC pauses are, out of the box, shorter than what most people will get by tuning the JVM. This is probably the most critical property for writing backend services with high fanout, which is very common at places like Google.
- Gibbon1 7y ago
  I don't have a dog in this be cause all I do is write embedded firmware and crummy tools that run under windows. But low latency is a better choice than throughput most of the time. My gut says when a system bogs down failures due to latency hits you first.
  - klodolph 7y ago
    I’m gonna go ahead and say that this is one of the reasons why people like Go so much. Latency is a big problem and becoming bigger as fanout increases, so the old defaults for tuning GC turn out to suck horribly. However, the throughput penalty is very real and e.g. compiling a large codebase I’d much rather have throughput tuning.

I don't know about the total memory overhead, but the Go team has written a lot about how their GC pauses are shorter.

I recently had to evaluate using Go vs Rust vs Java (current) and while Go did bring notable resource usage bonuses compared to JVM, Rust seemed to give significantly more if we did switch. The drawback of both Go and Rust for our group was that Java developers were so much more abundant in our market(not major technology hub city in the South). I think cities with smaller amounts of talent have the same problem when trying to find Go and Rust developers of all skill levels.

klodolph 7y ago

This is a reasonable question, so I’m unsure why it’s downvoted. It usually makes sense to talk about the memory overhead of the JVM itself, rather than talking about one of the languages specifically, like Java or Kotlin (but maybe Scala and Clojure are a bit different). The tradeoffs for GC systems are complicated and not easy to understand. Go supports only one GC system, as far as I know, which does not move memory and attempts to minimize GC pauses. It sacrifices throughput and CPU utilization to achieve this. The JVM can be tuned in many ways and there are a number of different options, from choosing different GC algorithms to different memory models. Most JVM algorithms will compact memory. Some are optimized for throughput and others are optimized for shorter pauses. In practice, my observation is that Go’s GC pauses are, out of the box, shorter than what most people will get by tuning the JVM. This is probably the most critical property for writing backend services with high fanout, which is very common at places like Google.

Gibbon1 7y ago
I don't have a dog in this be cause all I do is write embedded firmware and crummy tools that run under windows. But low latency is a better choice than throughput most of the time. My gut says when a system bogs down failures due to latency hits you first.
- klodolph 7y ago
  I’m gonna go ahead and say that this is one of the reasons why people like Go so much. Latency is a big problem and becoming bigger as fanout increases, so the old defaults for tuning GC turn out to suck horribly. However, the throughput penalty is very real and e.g. compiling a large codebase I’d much rather have throughput tuning.