Maybe D is right about GC after all !

[Paulo Pinto]

On Wednesday, 20 December 2017 at 08:49:18 UTC, Shachar Shemesh 
wrote:
> 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

I agree with you regarding C++ when I program alone, it is 
beautiful safe C++14 (now C++17) code.

However I completely disagree when I have to deal with the 
typical enterprise C++ code, that most of the time looks like C 
being compiled with a C++ compiler, from developers that learned 
it before C++98 and can't care less what is being discussed on 
Reddit and HN.

So I happily use Java and C# at work, only dealing with C++ for 
low level OS integration stuff, because that C++ that I am going 
to touch, written by such devs, will require gloves and tweezers.

--
Paulo