4 ms·

For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on

For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. For years until 1.19 the Go GC has had only one tuning parameter (GOGC).

tsimionescu 3y ago
Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
- philosopher1234 3y ago
  Which knobs does go need?
  - tsimionescu 3y ago
    Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
    - cwbriscoe 3y ago
      I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
    - kbolino 3y ago
      I agree with most of your points but how is it "old-fashioned"? To me, that means things like reference counting or long stop-the-world pauses, neither of which are true of Go.
rileymichael 3y ago
I don't see the connection you're making between knobs that adjust runtime behavior and tooling. As an aside, "you can't just run java code" is a bit hyperbolic, plenty of people "just run" java apps and rely on the default ergonomics. The modern JVM also offers more automated options, such as ZGC which is explicitly self tuning.
- iamcalledrob 3y ago
  With Go, you never spend hours/days debugging broken builds due to poorly documented gradle plugins. As an example :) You really, truly, just run.
  - pjmlp 3y ago
    That is the problem right there, using Gradle without having learned why no one uses Ant any longer. As for Go, good luck doing just run when a code repo breaks all those URL hardcoded in source code.
    - philosopher1234 3y ago
      That’s not a real issue: * the go module proxy ensures repos are never deleted, so everything continues to work * changing to a new dep is as easy as either a replace directive or just find and replace the old url
      - pjmlp 3y ago
        It requires work to keep things working, exactly the same thing.
        philosopher1234 3y ago
        The module proxy is used by default and requires no work. I don’t think what you’re saying makes much sense.
Ironlink 3y ago
> You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. This sounds like something you would hear 10 years ago in relation to the CMS garbage collector. Since Java 9, G1 has been the default gc for multi core workloads and is self-tuning. The CMS gc was removed 4 years ago. If you do need to tune G1, the primary knob is target pause time. While other knobs exist, you should think carefully before using them. We run all of our workloads with vanilla settings.

tsimionescu 3y ago

Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.

philosopher1234 3y ago
Which knobs does go need?
- tsimionescu 3y ago
  Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
  - cwbriscoe 3y ago
    I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
  - kbolino 3y ago
    I agree with most of your points but how is it "old-fashioned"? To me, that means things like reference counting or long stop-the-world pauses, neither of which are true of Go.

rileymichael 3y ago

I don't see the connection you're making between knobs that adjust runtime behavior and tooling. As an aside, "you can't just run java code" is a bit hyperbolic, plenty of people "just run" java apps and rely on the default ergonomics. The modern JVM also offers more automated options, such as ZGC which is explicitly self tuning.

iamcalledrob 3y ago
With Go, you never spend hours/days debugging broken builds due to poorly documented gradle plugins. As an example :) You really, truly, just run.
- pjmlp 3y ago
  That is the problem right there, using Gradle without having learned why no one uses Ant any longer. As for Go, good luck doing just run when a code repo breaks all those URL hardcoded in source code.
  - philosopher1234 3y ago
    That’s not a real issue: * the go module proxy ensures repos are never deleted, so everything continues to work * changing to a new dep is as easy as either a replace directive or just find and replace the old url
    - pjmlp 3y ago
      It requires work to keep things working, exactly the same thing.
      - philosopher1234 3y ago
        The module proxy is used by default and requires no work. I don’t think what you’re saying makes much sense.

Ironlink 3y ago

> You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. This sounds like something you would hear 10 years ago in relation to the CMS garbage collector. Since Java 9, G1 has been the default gc for multi core workloads and is self-tuning. The CMS gc was removed 4 years ago. If you do need to tune G1, the primary knob is target pause time. While other knobs exist, you should think carefully before using them. We run all of our workloads with vanilla settings.