Maybe D is right about GC after all !

[Shachar Shemesh]

On 19/12/17 11:54, Walter Bright wrote:
> "C, Python, Go, and the Generalized Greenspun Law"
> 
> http://esr.ibiblio.org/?p=7804
> 

I have two takeaways from that article:

1. ESR doesn't understand C++ one bit.
2. I feel exactly the same way about D.

I'll start with 1. I've been writing in C++ for a long time now, and 
have *never* had to spend much time on double frees/leaks. This is 
especially true since C++11, where the built-in types are good enough 
for anything which doesn't include graphs with cycles (and, yes, I would 
use a GC for those).

RAII + reference counting where needed pretty much eliminated those 
problems for me. ESR's lumping of C++ and C together, at the very least, 
lacks an explanation of why C++'s additional tools for handling this 
case are insufficient. A more likely case is that ESR is simply ignorant 
of them and their impact when used correctly.

The only times where I saw people mucking about with the allocators is 
when the *performance* profile was deemed not good enough. D's built-in 
facilities have nothing to offer on that front: The main case against 
the GC is it's horrid (and, worse, unexpected) performance.


I spend a lot of my time on D trying to work around the limitations that 
the GC is imposing on me, to the point where I feel like much we do here 
is to write our own infrastructure, because we can't use the built-in 
one. To be clear, the problem is a performance one here too, but the 
handling is completely different.

In C++ it is possible to start with the built-in facilities and then 
slowly work alternative ones as bottlenecks are analyzed. No such path 
is possible in D. If you don't want to use the GC, you will need to 
rework *everything*. Your entire code will have to revolve around using 
non-GC facilities, most of which you will have to write for yourself.

So, no, I'm not convinced.

Shachar