What's the go with the GC these days?

[Walter Bright]

On 1/5/2019 11:58 PM, Manu wrote:
> I was very much 'there' when this was rejected by the community. I
> don't think it 'failed to gain traction' despite trying, so much as it
> was just plain rejected or dismissed.
> And not for any particularly good reason. It went like this among the
> ~hundreds of programmers I interacted with at the time.
> 1. "Managed C++" is code for "lame C#", or just "C# interop layer"
> 2. C++ users want absolutely nothing to do with C#, and nothing to do
> with the word 'managed'
> 3. C# users want absolutely nothing to do with C++
> 4. The feature didn't stand alone as a C++ feature
> 5. Even if it did, it was limited to windows, and to MS compilers.
> Completely not-portable.

I had a lot of experience with multiple pointer types from the DOS world. While 
it works, it is a constant headache. With every .. single .. pointer one had to 
decide near*? far*? ss*? cs*? huge*? and Zortech's vptr*? and of course every .. 
single .. data .. structure had the same issues, and no, they could not 
interoperate.

Programmers (myself included) were very happy to abandon that way of doing things.


> It's obvious why it failed. I don't think comment on the merit of the
> design has any relevance at all to that particular story.
> The particulars of the design and whether it was good or not couldn't
> have had less affect on the feature being ignored and/or rejected.

It had a large effect in my experience. I'm an expert on near/far/etc, and I 
don't miss it like I don't miss EBCDIC. I was kinda glad to see Managed C++ 
fail, so I wouldn't get any pressure to implement it.

(I also recall programmers looking at it, and respond "two kinds of pointers? 
Blech." Not just me.)


>>> Either the speed has improved, or they're just eating the time cost.
>>
>> The fact that Java/Go/etc. use inserted write gates suggest the speed hasn't
>> improved, which leaves eating the cost.
> 
> Could D insert such code, and also effectively elide it where @nogc is
> used (or inferred)?

@nogc code means no allocations happen, not that there are no pointers to the gc 
in the code. It's orthogonal.


> If we can help the GC in common code, but still have the expressive
> power we need to elide that extra work where we know it's not
> necessary, then it might be reasonable to consider.

If we could do that, we wouldn't need GC, the compiler could figure out the last 
use of each pointer. With all the research into GCs, nobody has ever figured 
that out.