5 ms·

I've seen you rebut Ian's remarks a number of times. I'm not sufficiently knowledgeable about GCs, but I would really like to hear some of his responses to your

I've seen you rebut Ian's remarks a number of times. I'm not sufficiently knowledgeable about GCs, but I would really like to hear some of his responses to your criticisms. I think I (and probably lots of others) would learn a lot from the debate.

geodel 8y ago
There is most likely none. Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered. This debate about Generational GC is theoretical in nature, claiming Java GC design is universally applicable irrespective of language and its use cases. There may indirect approval to Go approach by Java when developing value types: http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 key Quote: "In modern JVMs, object allocation is inexpensive, with a cost comparable to out-of-line procedure calling. But even this cost is often a painful overhead when compared to individual operations on primitive values. Thus, Java programmers face a binary choice between existing primitive types (which avoid allocation) and other types (which allow data abstraction and other benefits of classes). When they need to define small composite values such as complex numbers, pixels, or pairs of return values, neither approach serves. This dilemma often has no good solution, and the workarounds distort Java programs and APIs. " If we go by claims that Java and its GC supporters always made: 1) RAM is Cheap 2) GC is incredibly fast so as not to worry about allocation. There should be no need to waste tremendous multi year engineering effort to add value types to Java.
- openasocket 8y ago
  That's a straw man. Just because GC is fast doesn't mean it can't be made faster. > Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered. That's not just an appeal to authority, that's a big assumption. As far as I know, no Go maintainer has claimed that they have gathered large amounts of performance data and concluded that a generational GC wouldn't improve performance. Also, calling generational GC "Java GC design" is disingenuous. Generational GC long precedes the creation of Java, and is used almost universally. Common Lisp (various implementations), .Net, the Lua VM (and the LuaJIT VM), BEAM, SELF, and Haskell (GHC at least) all use generational garbage collection. In fact, the current Go implementation is the only GC implementation I'm aware of that isn't generational.
  - geodel 8y ago
    I think it is other way round. No one has yet shown in production applications that Go's GC throughput is big problem for them.
    - pcwalton 8y ago
      The question to ask is: Have people switched away from Go for certain applications in order to get better CPU-bound performance? Yes, they have. GC throughput is one part of the reason why Go code is often suboptimal for CPU-bound workloads. Adding a generational GC won't solve this, but it's bound to help.
      - weberc2 8y ago
        I don’t think “has anyone ever switched from Go...” is particularly meaningful. Is the switch common? I’ve only heard of a handful (like 3) of cases where people tried optimizing Go and found it to be lacking, and those cases were at the extreme end of the performance spectrum. Also, Go will never be optimally performant because it chooses to balance performance with competing concerns (safety, simplicity, etc), so its unclear in those cases whether the suboptimalism was due to Go’s GC scheme or to other trade offs.
  - yoklov 8y ago
    Neither Lua nor LuaJIT use a generational design, they're both tri-color incremental mark and sweep collectors without a separate nursery. There was a plan for a generational GC for LuaJIT [0] (not to mention a lot of other cool features and a very clever design) but it was never implemented (and at this point it probably never will be). [0] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
    - weberc2 8y ago
      Also, most of the listed languages don’t have value types or added them expressly because their GC scheme was insufficient.
- pcwalton 8y ago
  It does not follow that, because value types allow heap allocation to be avoided in some cases, it's not worth investing in making heap allocation faster. That's why I made the observation upthread to begin with.
cdoxsey 8y ago
So for some context here, the work on the Go garbage collector was done by experts, for example: Rick Hudson (https://www.linkedin.com/in/richard-hudson-33339185/ https://www.linkedin.com/in/richard-hudson-33339185/). These guys knew the state of the art, and made the decision they thought was best for Go. This is an incredibly technical area of discourse, and sadly, hacker news probably isn't going to be the place to see it happen. But the whole idea that Go is made of a bunch of strongly-opinionated, insular developers who have no idea what they're doing is hogwash, especially in this area. Go had a sub-par garbage collector and Google put together serious resources to fix it.
- pcwalton 8y ago
  Note that I've never said that Go developers don't have any idea what they're doing. Very smart, competent people can be wrong. I know I'm wrong a lot! For what it's worth, I've also heard that Go is considering moving to a generational GC, in spite of Ian's initial arguments against it. Hopefully they do.
  - weberc2 8y ago
    Presumably after being in production for years, the very smart, competent developers would admit their error (if indeed they should have used a generational GC), right? Hubris? I'm trying to square these remarks with your cut-and-dry portrayal of the issue.

geodel 8y ago

There is most likely none. Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered. This debate about Generational GC is theoretical in nature, claiming Java GC design is universally applicable irrespective of language and its use cases. There may indirect approval to Go approach by Java when developing value types: http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 key Quote: "In modern JVMs, object allocation is inexpensive, with a cost comparable to out-of-line procedure calling. But even this cost is often a painful overhead when compared to individual operations on primitive values. Thus, Java programmers face a binary choice between existing primitive types (which avoid allocation) and other types (which allow data abstraction and other benefits of classes). When they need to define small composite values such as complex numbers, pixels, or pairs of return values, neither approach serves. This dilemma often has no good solution, and the workarounds distort Java programs and APIs. " If we go by claims that Java and its GC supporters always made: 1) RAM is Cheap 2) GC is incredibly fast so as not to worry about allocation. There should be no need to waste tremendous multi year engineering effort to add value types to Java.

openasocket 8y ago
That's a straw man. Just because GC is fast doesn't mean it can't be made faster. > Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered. That's not just an appeal to authority, that's a big assumption. As far as I know, no Go maintainer has claimed that they have gathered large amounts of performance data and concluded that a generational GC wouldn't improve performance. Also, calling generational GC "Java GC design" is disingenuous. Generational GC long precedes the creation of Java, and is used almost universally. Common Lisp (various implementations), .Net, the Lua VM (and the LuaJIT VM), BEAM, SELF, and Haskell (GHC at least) all use generational garbage collection. In fact, the current Go implementation is the only GC implementation I'm aware of that isn't generational.
- geodel 8y ago
  I think it is other way round. No one has yet shown in production applications that Go's GC throughput is big problem for them.
  - pcwalton 8y ago
    The question to ask is: Have people switched away from Go for certain applications in order to get better CPU-bound performance? Yes, they have. GC throughput is one part of the reason why Go code is often suboptimal for CPU-bound workloads. Adding a generational GC won't solve this, but it's bound to help.
    - weberc2 8y ago
      I don’t think “has anyone ever switched from Go...” is particularly meaningful. Is the switch common? I’ve only heard of a handful (like 3) of cases where people tried optimizing Go and found it to be lacking, and those cases were at the extreme end of the performance spectrum. Also, Go will never be optimally performant because it chooses to balance performance with competing concerns (safety, simplicity, etc), so its unclear in those cases whether the suboptimalism was due to Go’s GC scheme or to other trade offs.
- yoklov 8y ago
  Neither Lua nor LuaJIT use a generational design, they're both tri-color incremental mark and sweep collectors without a separate nursery. There was a plan for a generational GC for LuaJIT [0] (not to mention a lot of other cool features and a very clever design) but it was never implemented (and at this point it probably never will be). [0] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
  - weberc2 8y ago
    Also, most of the listed languages don’t have value types or added them expressly because their GC scheme was insufficient.
pcwalton 8y ago
It does not follow that, because value types allow heap allocation to be avoided in some cases, it's not worth investing in making heap allocation faster. That's why I made the observation upthread to begin with.

cdoxsey 8y ago

So for some context here, the work on the Go garbage collector was done by experts, for example: Rick Hudson (https://www.linkedin.com/in/richard-hudson-33339185/ https://www.linkedin.com/in/richard-hudson-33339185/). These guys knew the state of the art, and made the decision they thought was best for Go. This is an incredibly technical area of discourse, and sadly, hacker news probably isn't going to be the place to see it happen. But the whole idea that Go is made of a bunch of strongly-opinionated, insular developers who have no idea what they're doing is hogwash, especially in this area. Go had a sub-par garbage collector and Google put together serious resources to fix it.

pcwalton 8y ago
Note that I've never said that Go developers don't have any idea what they're doing. Very smart, competent people can be wrong. I know I'm wrong a lot! For what it's worth, I've also heard that Go is considering moving to a generational GC, in spite of Ian's initial arguments against it. Hopefully they do.
- weberc2 8y ago
  Presumably after being in production for years, the very smart, competent developers would admit their error (if indeed they should have used a generational GC), right? Hubris? I'm trying to square these remarks with your cut-and-dry portrayal of the issue.