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
