← Back to context

Comment by pjmlp

6 hours ago

They are considered in many research labs since Xerox, unfortunately there are still too much anti-GC religion among mainstream devs.

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill.

Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

  • Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it.

    It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either.

    That a GC is adverse to the performance both latency-oriented and throughput-oriented workloads doesn't leave many use cases in "high-performance" systems. Maybe systems that are severely I/O bound but is barely a thing these days.

    • > Maybe systems that are severely I/O bound but is barely a thing these days.

      Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment.

      > High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either

      Games are high-performance throughput-optimized systems that have adopted GC languages for 15+ years now, and again a type of application which is much more latency sensitive than most people deal in their day to day.

      Nobody is claiming GC is a panacea, but it’s good enough for a lot more use cases people give it credit for.

    • Could you elaborate on "GCs are not used there [high-performance throughput-optimized systems]"? Are you referring to the cascading effects of tail latency on systems with high fanout?