3 ms·

> Systems and time sensitive languages cannot have GC. This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system al

• pcwalton 11y ago
  > This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system allowing you to manage/batch your allocations and sweeps. Root all your allocations for the inner loop, and unroot them/trigger a release when ready. Not for all allocations. You can manually do it for a subset of them, but pooling all allocations is generally extremely impractical. How do you, for example, pool the allocations that closures or defer perform?
  • duaneb 11y ago
    > How do you, for example, pool the allocations that closures or defer perform? It's a strange area that demands reliable or stable performance but uses closures and exceptions, two ways to inject a healthy amount of noise into your understanding of the program, and certainly blows the upper bound on "arbitrary wait time" to huge. I haven't been presented with a problem yet that allowed you to complain about GC with respect to latency where you would want implicit allocations happening all over the case....
    • pcwalton 11y ago
      You can't get away from exceptions in Go. Closures, maybe, depending on the code you're writing (though I doubt it), but the highly dynamic semantics of defer makes it impossible to avoid.