Future of memory management in D

russhy russhy at gmail.com
Wed Nov 17 04:41:46 UTC 2021


On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
> 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 can't believe this is what still being debated, yet again..

--

D's GC:

- doesn't scale, the more pointers to scan the slower the 
collection is
- stop the entire world whenever a collection happen
- no R&D

What's your use case with this?


And you want to attract what kind of people? in a cloud native 
world with such GC? what kind of people will you attract if you 
are doing worse than NodeJS's GC? scripters? is that what D is? a 
language for scripters? want to replace BASH, is that it?



--


You complain about @nogc being what the "gc phobic" people 
wanted, and yet they didn't come?

People don't want tags, they want a platform where they can use 
D, not "annotated" D

--

-betterC failed to bring C/C++ people?


Yeah, i mean..

```D
struct Test
{
     float[32] data;
}

extern (C) int main()
{
     Test b;
     Test c;

     bool r = b == c;

     return 0;
}
```

this code doesn't compile in -betterC, who will you attract if 
such basic and common code doesn't work?

also it sounds like it is some bone you give to a dog so he can 
play and you relax in peace, not a good message


fragmentation, that's what you get


--

GO became ultra popular thanks to **its** GC and its 
applications, not because **of a** GC, big difference ;)

--

bandaid solutions doesn't attract people, saying "we have a no GC 
story at home" BUT you have to do X, Y, Z, and give up on A, B, C 
is not what the people wanted and that you gave the "@nogc tag" 
and the "non functioning -betterc"

they want what Rust provide, a modern system programming language

they want what Zig provide, a modern system programming language

they want what Odin provide, a modern system programming language

they want what Jai provide, a modern system programming language


--

Don't expect those people to want a modern Java alternative


Because GO already took that role, something D could have done, 
and yet didn't, you have a GC, why it failed? why people 
complained about a GC in D? but not a GC in GO?, this is the 
message you REFUSE to hear


--

There are no GC-phobia, there is a poor's man GC phobia!, big 
difference

Instead of investing billions into a competitive GC, with nobody 
wants to do, including the GC advocators, let's adopt the 
Allocator aware mindset, it's much cheaper, and much more 
effective ;)







More information about the Digitalmars-d mailing list