Would you pay for GC?

[Paulo Pinto]

On Tuesday, 25 January 2022 at 06:13:31 UTC, Random Dude wrote:
> On Tuesday, 25 January 2022 at 03:37:57 UTC, Elronnd wrote:
>> Apropos recent discussion, here is a serious question: would 
>> you pay for either of these?
>>
>> - High-throughput/scalable gc.  High sustained allocation 
>> rates, large heaps, many cores, compacting&generational
>>
>> - Concurrent gc.  No pauses
>
> I'd pay to have it removed and replaced with ARC.
>
> GC in it's current form can not compete with other more 
> performant GCs and it shouldn't. D is in a unique position to 
> enable people to write code as if they're writing python and 
> also accommodate them when they want to do low-level 
> optimizations.
>
> If we could just have automatic reference counting both the GC 
> and No-GC people would be happy. It's okay if that route 
> changes how pointers work (metadata would have to be added and 
> some code would break), this is the right move in the long run.

ARC will also not compete, unless one goes the extra mile of 
making the compiler ARC aware, elide retain/release calls, do 
cascade deletions in background threads, take care on cascade 
deletions to avoid stack overflows on destructor calls, provide 
multicore friendly versions of them,.....

If you are paying to replace GC with ARC, without putting the 
money to reach Swift level of performance (which is still pretty 
lame versus last gen tracing GCs in Java/.NET), then you will be 
getting lemons.

https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206

I can already see it, the forums being inundated with complains 
about ARC performance versus other languages.