forcing "@nogc" on class destructors

[via Digitalmars-d]

On Wednesday, 21 January 2015 at 00:47:43 UTC, deadalnix wrote:
> On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim 
> Grøstad wrote:
>> On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
>>>> Concurrent GC is too expensive for a proper system level 
>>>> language.
>>>>
>>>
>>> That is an unsubstanciated claim.
>>
>> And so is «pigs can't fly».
>>
>
> That is the old prove a negative bullshit.

No. You can make a pig fly, but the landing is going to be ugly 
compared to the competition.

The status quo is that GC is not desirable in typical real time / 
system level programming. And if it is to be used, it should be 
predictable and not require special code gen.

So that is hypothesis h0. Then it is up to you to replace it with 
hypothesis h1: "concurrent GC is fine for typical system level 
programming".

All you have to do is to provide a documented proof-of-concept, 
or at least a link to a solid paper that describes a concurrent 
GC that has the desired properties:

1. no negative effect on code gen
2. predictable upper bounds all around (time, latency and memory)
3. no bad pollution of caches at the wrong time
4. no intermittent pauses at random times

> You assert that something is too expensive for system language, 
> which is not a negative, so the burden of proof is on you, 
> substantiate your claim or you are just generating noise.

Oh... But you are the one that is challenging the status quo. Not 
me. The excitement created by Rust is proof enough for what the 
status quo is.

> Relying on cheap rhetorical trick is not going to fly (and you 
> could add, no more than a pig).

GC is an unnecessary pig to begin with. If you want to use a pig 
to eat your leftovers, then you need to know how hungry it is and 
how much and how fast it can eat. I think the metaphor is apt. :-)