Future of memory management in D

[H. S. Teoh]

On Wed, Nov 17, 2021 at 01:57:23AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 17 November 2021 at 01:32:50 UTC, H. S. Teoh wrote:
> 
> Can I make full use of the `STD` library without garbage collection?
> If this is achieved, it can be advertised everywhere.
> ,Then why not remove `GC` on the home page?.

Why bend over backwards to please the GC-phobic crowd?  They've already
made up their minds, there's no convincing them.

Having a GC IME is an extremely powerful thing, contrary to what the GC
haters will tell you.  It frees up your APIs from being littered with
memory-management minutiae.  It makes your APIs clean, refactorable, and
maintainable.  Easy to use.  It makes your code clean.  You get to make
progress in your problem domain instead of wasting 75% of your brain
power thinking about memory management at every step.  You save
countless hours writing manual memory management code, and countless
more hours debugging said code.

And in D, you also get to choose to use manual memory management in
performance bottlenecks *where it actually matters*. 90% of application
code is not on the hot path, it's a completely waste of effort to
meticulously manage memory in such code, when you could be focusing your
efforts on the 10% hot path where 90% of the performance gains are made.

Writing code without a GC is wasteful of programmer time, which equals
to wasting money paying programmers to do something that should have
been done in 10% of the time, leaving the rest of the time to work on
things that actually matter, like implementing features and making
progress in your problem domain.  You spend tons of wages paying said
programmers to debug memory-related bugs, which are notorious to be
extremely hard to find and require a lot of time, when these wages could
have been used to pay them to implement new features and drive your
business forward.  *And* you waste tons of wages paying them to maintain
code that's needlessly complex due to having to manually manage memory
all the time.  It takes a lot of time and effort to maintain such code,
time that could have been diverted for more useful work had a GC been in
place.

And you know what?  In spite of all this time and effort, programmers
get it wrong anyway -- typical C code is full of memory leaks, pointer
bugs, and buffer overflows.  Most of them are latent and only trigger in
obscure environments and unusual inputs, and so lie undiscovered,
waiting for the day it suddenly explodes on a customer's production
environment.  Or somebody comes up with a security exploit...

With a GC, you instantly eliminate 90% of these problems.  Only 10% of
the time, you actually need to manually manage memory -- in inner loops
and hot paths where it actually matters.

GC phobia is completely irrational and I don't see why we should bend
over backwards to please that crowd.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly