Escaping the Tyranny of the GC: std.rcstring, first blood

[Andrei Alexandrescu via Digitalmars-d]

On 9/24/14, 7:16 PM, Manu via Digitalmars-d wrote:
[snip]

Thanks for answering. I've figured I have no meaningful answer to this, 
but allow me to elaborate why out of respect.

Apologies for letting go of the horses a little. An explanation (but not 
an excuse) is that Walter and I are humans and as much as we do our best 
to keep levelheaded at all times we get a tad frustrated.

These are heady days for D. We're more optimistic than ever about future 
prospects and possibilities, which we hope to confirm publicly soon. We 
have a very strong vision (C++ and GC, C++ and GC...) and we have 
designs realizing it that we believe we can make work. This is literally 
the best time in the history of D for the community to help us. Amid 
this feverish preparation (we talk some 15-45 minutes on the phone every 
day), we find ourselves stumped by the occasional idle chatter on 
inconsequential matters that sometimes descends into a spiral of 
gratuitous negativity. Or wine party, as graciously dubbed by Walter.

I have difficulty communicating with you, to the extent that I very 
candidly have no idea what you're trying to accomplish, and how you 
propose language technology to help you. But I think it's possible to 
improve on that.

One simple rule of thumb is to pop one level up and describe the task 
you're trying to accomplish, instead of describing at low level what you 
believe would be obviously the language-based solution. Two examples:

1. You say "if ref were part of a type" and not only say it, but also 
build on the good presumed consequence of it. That can't be done in D, 
simple as that. We can't flip a switch and do it. The ripples throughout 
the entire fabric of the language would essentially transform it in a 
whole different language, with most rules subtly different from today's. 
You yourself confessed "I'm not a language developer, I don't want to 
be." Then the best route is to focus on the high-level task as opposed 
on what you believe would be the language change fixing it. Please take 
this as kindly as I mean it: most language-space solutions you propose 
are alien and unworkable.

2. You wrongly believe language solutions are innately better than 
engineering solutions. Please understand that no amount of notation 
would save you from the issues you encounter with RefCounted. Also, your 
notion that optimization technology only kicks in for language-baked 
artifacts is wrong. Please trust us on this: YES, we can define 
increment and decrement in libraries in such a way they're elided if 
they cancel themselves out. I find it very difficult to sympathize with 
you completely dismissing library engineering solutions for vague 
reasons, which, from what I can tell, no amount of built-in notation can 
save you.

What I hope to come out of this is a clear idea of what you're trying to 
accomplish (not "I want ref part of the type", but "I want to write a 
framework that does ..."), and how you find the current offering in the 
language + standard library + your own custom libraries wanting. Can we 
get that kind of dialog going?


Andrei