6 ms·

Just trying to understand if this is what simple looks like.

coder543 4y ago
2 knobs after a decade vs how many in Java? Yes, that is exactly what simple looks like. After years of real world experience, I can say that the Go garbage collector worked fantastically across a range of applications that I've been involved in. No tool is perfect for every job, of course, and having hundreds of knobs does not make Java perfect for every job either.
- staticassertion 4y ago
  - coder543 4y ago
    You clearly seem to be here to troll / just crap on Go while trying to appear fake-earnest, and that goes against HN guidelines. I believe this falls under "sneering". I've actually also used Rust plenty in professional contexts over the last five years. Once again: no tool is perfect for every job.
    - staticassertion 4y ago
      - coder543 4y ago
        As I recall, C#'s GC famously has very few knobs as well. I don't think you can swap the GC implementation, either, which is a source of even more complexity in the world of Java.
  - dang 4y ago
    Please stop.
- eikenberry 4y ago
  I'd say it makes Java's GC worse at nearly every job as that means the defaults probably aren't what you want but are probably what you are going to use.
  - truffdog 4y ago
    The Java problem is that you wind up in a blame game where one team blames the code and the other blames the GC settings and you wind up doing a lot of fruitless flailing. No knobs really cuts down on that nonsense.
  - vips7L 4y ago
    In situations where you actually are allocating on the heap, Java’s default GC significantly out performs Go’s. Just look at the binary tree bench marks. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - coder543 4y ago
      Even that simplification is too much. Java uses a generational GC, so the fewer objects that survive the nursery, the less work it has to do. That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It means Java's GC is faster when you're spewing garbage onto the heap as fast as possible. Since Go makes heavy use of stack allocation where possible, short-lived garbage usually doesn't end up on the heap, but this benchmark is designed to force that outcome. Go's garbage collector is optimized to minimize latency and STW, but this does come at the cost of decreased throughput. The opposite can be said of the majority of Java GC implementations, which trade latency and STW time for increased throughput.
      - vips7L 4y ago
        > Java uses a generational GC. This depends on implementation. ZGC is not generational yet, but I don’t see how generational or not would invalidate a GC benchmark for the default implementation. > That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It actually does at least in the discussion of _default gc implementations_. Just because the default (and only) implementation for Go sacrifices throughput (and relies on the compiler to stack allocate) doesn’t invalidate the benchmark. And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.
bit_flipper 4y ago
I had a look through some of your comments here and elsewhere and just wanted to give you some friendly feedback: This style of commenting is quite toxic. I think you'll feel happier if you let go of the tribalism and engage with others in good faith.
- staticassertion 4y ago
  I engage in good faith conversations all the time.
- MichaelMoser123 4y ago
  why is asking questions regarded as toxic? I genuinely want to know
  - _ph_ 4y ago
    It is not about asking questions in general, it is about asking questions in a suggestive way, if it suggests something toxic.
icholy 4y ago
Go look in a mirror for an example of simple

2 knobs after a decade vs how many in Java? Yes, that is exactly what simple looks like. After years of real world experience, I can say that the Go garbage collector worked fantastically across a range of applications that I've been involved in. No tool is perfect for every job, of course, and having hundreds of knobs does not make Java perfect for every job either.

staticassertion 4y ago
- coder543 4y ago
  You clearly seem to be here to troll / just crap on Go while trying to appear fake-earnest, and that goes against HN guidelines. I believe this falls under "sneering". I've actually also used Rust plenty in professional contexts over the last five years. Once again: no tool is perfect for every job.
  - staticassertion 4y ago
    - coder543 4y ago
      As I recall, C#'s GC famously has very few knobs as well. I don't think you can swap the GC implementation, either, which is a source of even more complexity in the world of Java.
- dang 4y ago
  Please stop.
eikenberry 4y ago
I'd say it makes Java's GC worse at nearly every job as that means the defaults probably aren't what you want but are probably what you are going to use.
- truffdog 4y ago
  The Java problem is that you wind up in a blame game where one team blames the code and the other blames the GC settings and you wind up doing a lot of fruitless flailing. No knobs really cuts down on that nonsense.
- vips7L 4y ago
  In situations where you actually are allocating on the heap, Java’s default GC significantly out performs Go’s. Just look at the binary tree bench marks. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - coder543 4y ago
    Even that simplification is too much. Java uses a generational GC, so the fewer objects that survive the nursery, the less work it has to do. That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It means Java's GC is faster when you're spewing garbage onto the heap as fast as possible. Since Go makes heavy use of stack allocation where possible, short-lived garbage usually doesn't end up on the heap, but this benchmark is designed to force that outcome. Go's garbage collector is optimized to minimize latency and STW, but this does come at the cost of decreased throughput. The opposite can be said of the majority of Java GC implementations, which trade latency and STW time for increased throughput.
    - vips7L 4y ago
      > Java uses a generational GC. This depends on implementation. ZGC is not generational yet, but I don’t see how generational or not would invalidate a GC benchmark for the default implementation. > That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It actually does at least in the discussion of _default gc implementations_. Just because the default (and only) implementation for Go sacrifices throughput (and relies on the compiler to stack allocate) doesn’t invalidate the benchmark. And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.

bit_flipper 4y ago

I had a look through some of your comments here and elsewhere and just wanted to give you some friendly feedback: This style of commenting is quite toxic. I think you'll feel happier if you let go of the tribalism and engage with others in good faith.

staticassertion 4y ago
I engage in good faith conversations all the time.
MichaelMoser123 4y ago
why is asking questions regarded as toxic? I genuinely want to know
- _ph_ 4y ago
  It is not about asking questions in general, it is about asking questions in a suggestive way, if it suggests something toxic.

icholy 4y ago

Go look in a mirror for an example of simple