You don't like GC? Do you?

[Stanislav Blinov]

On Friday, 12 October 2018 at 21:39:13 UTC, Atila Neves wrote:

> 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.

Then five years later, try and hunt down that mysterious heap 
corruption. Caused by some destructor calling into buggy 
third-party code. Didn't want to think about that one either?

> 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.

There is no "sometimes" here. You're writing programs for 
specific machines. All. The. Time.

>> 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.

All code is performance sensitive. Whoever invented that 
distinction should be publicly humiliated. If it's not speed, 
it's power consumption. Or memory. Or I/O. "Not thinking" about 
any of that means you're treating your power champion horse as if 
it was a one-legged pony.
Advocating the "not thinking" approach makes you an outright evil 
person.