You don't like GC? Do you?

[Atila Neves]

On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov 
wrote:
> On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson 
> wrote:
>
>> Freeing your mind and the codebase of having to deal with 
>> memory leaves it in an easier place to deal with the less 
>> common higher impact leaks: file descriptors, sockets, 
>> database handles ect. (this is like chopping down the forest 
>> so you can see the trees you care about ;) ).
>
> That's done first and foremost by stripping out unnecessary 
> allocations, not by writing "new" every other line and closing 
> your eyes.

D isn't Java. If you can, put your data on the stack. If you 
can't, `new` away and don't think about it. The chances you'll 
have to optimise the code are not high. If you do, the chances 
that the GC allocations are the problem are also not high. If the 
profiler shows they are... then remove those allocations.

> I mean come on, it's 2018. We're writing code for multi-core 
> and multi-processor systems with complex memory interaction.

Sometimes we are. Other times it's a 50 line script.

> Precisely where in memory your data is, how it got there and 
> how it's laid out should be bread and butter of any D 
> programmer.

Of any D programmer writing code that's performance sensitive.

> It's true that it isn't critical for one-off  scripts, but so 
> is deallocation.

We'll agree to disagree.

> Saying stuff like "do more with GC" is just outright harmful.

Disagreement yet again.