Garbage Collector?

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
> On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner 
> wrote:
>> D just does this transparently for you by default. If you 
>> already know the exact or maximum size, you can allocate 
>> *once* (not 6 times) using `new` and `.reserve` respectively 
>> *before* entering the loop, like that article explains in 
>> depth.
>
> You seem to be missing the fact that i pointed this out. The 
> fact that the GC might have done up to 6 collection rounds in 
> that loop is "ludicrous".

You wrote:
> I if did my own memory management, the variable cleanup will 
> have been done in one go, right after the loop. Simply more 
> efficient.

You wrote about cleaning up *after* the loop, *not* about 
allocating *before* the loop. They are semantically related (as 
allocating with the GC *might* kick off a collection cycle), but 
not the same thing.

>
>> In my experience most people's aversion to GCs can be aptly 
>> described by the German proverb "Was der Bauer nicht kennt, 
>> das frisst er nicht" (the meaning of which being that most 
>> people generally like living in comfort zones and rarely - if 
>> ever - dare to leave them of their own free will; that 
>> includes developers, sadly).
>
> Unfortunately i do have plenty of experience with GC kicking in 
> on the wrong moments ( or not at the right moments, people 
> forget that one ).

In which language(s)? Because in D it's both easy and simple to 
avoid that (Use @nogc or compile with `-vgc` and inspect).

>
> Maybe its my opinion only but a good language will not put 
> anything in the way of the developer but will point out 
> mistakes.

Safety properties may be what you're looking for. See @safe, 
that's an area of D a lot of work is currently being done on.

>
> The Rust compiler is not a bad example but it can be taken a 
> step more. Is it so hard for developers when you declare a 
> variable, to later also clean it up???
>
> var x = 1;
> // Do work
> x.free;

If you write it like that, yes, because often it's not just one 
such make/dispose pair per scope, but multiple, possibly 
overlapping ones and people make mistakes. And the more complex a 
piece of code gets the harder it becomes to decipher such pairs 
and/or decide if the "closing" dispose is missing.
This is one of the reasons why scope guards are good:

var x = 1;
scope (exit) x.free
// Do work

This, as code becomes more complex, allows for much easier 
reading (and understanding) of lifetimes.


>
> Easy ... Sure, it becomes a little bit more tricky with 
> ownership but that is where the compiler can help and simply 
> state: "Hey, you forgot this variable, it does not seem to be 
> used beyond this point".

Since the GC is memory safe by definition (sans bugs) you'd only 
need this for where you aren't using it. And for the rest I'm not 
sure it can be done sanely: How's the compiler to know, e.g., 
which functions from a C API (or C++) you call into allocate or 
deallocate memory? Introduce yet another keyword or @property to 
signal cross-language memory management? If you ignore 
cross-language calls and only remain within D, I suppose it might 
be viable to write a semantic pass for it, but from my 
perspective, the cross-language calls are the *much* bigger 
threat to memory safety.

> Just calling the x.free seem to be too much work for developers 
> these days.

In my experience reading about such occurences, this usually 
happens when the lifetime of the object the memory is used for 
has become unclear.

>
> Up to now i found very few languages that did this correctly.

I don't share your assessment of what's correct, but yes, we 
digress.