Jump to page: 1 214  
Page
Thread overview
Future of memory management in D
Nov 16
Rumbu
Nov 16
IGotD-
Nov 17
jmh530
Nov 17
IGotD-
Nov 17
jmh530
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
zjh
Nov 17
bachmeier
Nov 17
zjh
Nov 17
forkit
Nov 17
zjh
Nov 17
russhy
Nov 17
Tejas
Nov 17
Tejas
Nov 17
Zoadian
Nov 17
bachmeier
Nov 18
bachmeier
Nov 18
JN
Nov 18
zjh
Nov 17
forkit
Nov 17
forkit
Nov 17
forkit
Nov 17
Tejas
Nov 18
rumbu
Nov 18
forkit
Nov 18
rumbu
Nov 18
Rumbu
Nov 18
Rumbu
Nov 18
Tejas
Nov 18
rumbu
Nov 18
JN
Nov 18
Rumbu
Nov 19
Dom DiSc
Nov 19
Dom DiSc
Nov 19
rumbu
Nov 20
Dom DiSc
Nov 20
Rumbu
Nov 20
Rumbu
6 days ago
russhy
November 16

At least from my point of view, it seems that recently D made a shift from a general purpose language to a C successor, hence the last efforts to improve betterC and C interop, neglecting other areas of the language.

By other areas I mean half baked language built-ins or oop support which failed to evolve at least to keep the pace with the languages from where D took inspiration initially (e.g. Java and its successors).

In this new light, even I am not bothered by, I must admit that the garbage collector became something that doesn't fit in.

Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?

For library development it is not necessary a big deal since the allocator pattern can be implemented for each operation that needs to allocate.

But, for the rest of the features which are part of the core language (e.g. arrays, classes, exceptions) what memory model do you consider that will fit in? Do you think that compiler supported ARC can be accepted as a deterministic memory model by everyone? Or memory ownership and flow analysis are better?

Not assuming a standard memory model can be a mistake, the C crowd will always complain that they cannot use feature X, others will complain that they cannot use feature Y because it is not finished or its semantics are stuck in 2000's.

November 16
On Tue, Nov 16, 2021 at 06:17:29PM +0000, Rumbu via Digitalmars-d wrote: [...]
> In this new light, even I am not bothered by, I must admit that the garbage collector became something that doesn't fit in.
> 
> Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?
[...]

You can take the GC from me over my cold dead body.


T

-- 
Study gravitation, it's a field with a lot of potential.
November 16
On Tuesday, 16 November 2021 at 18:25:53 UTC, H. S. Teoh wrote:
> On Tue, Nov 16, 2021 at 06:17:29PM +0000, Rumbu via Digitalmars-d wrote: [...]
>> In this new light, even I am not bothered by, I must admit that the garbage collector became something that doesn't fit in.
>> 
>> Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?
> [...]
>
> You can take the GC from me over my cold dead body.
>
>
> T

😂

I'm not that dramatic. But research suggests GC is actually a good invention. For me the thing about D is its plasticity. That you can choose.

But, yes, to be able to choose, the stdlib must not rely on gc as much.

But I really want the GC there if I need it.
November 16

On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:

>

Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?

Not assuming a standard memory model can be a mistake, the C crowd will always complain that they cannot use feature X, others will complain that they cannot use feature Y because it is not finished or its semantics are stuck in 2000's.

The Achilles heel of D and its memory management was never the GC itself or GC/not GC. It was that D didn't separate raw pointers from managed pointers as different types. If D had done that, it would have many more options.

This borrow checker implementation in D, I'm not sure what the purpose is and I don't have the whole picture either.

November 16
On Tue, Nov 16, 2021 at 10:38:13PM +0000, IGotD- via Digitalmars-d wrote:
> On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:
> > 
> > Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?
> > 
> > Not assuming a standard memory model can be a mistake, the C crowd will always complain that they cannot use feature X, others will complain that they cannot use feature Y because it is not finished or its semantics are stuck in 2000's.
> 
> The Achilles heel of D and its memory management was never the GC itself or GC/not GC. It was that D didn't separate raw pointers from managed pointers as different types. If D had done that, it would have many more options.
[...]

That may be true, but having multiple incompatible pointer types mixed together in the language makes code far more complex (and prone to bugs). The type system would be a lot more complex than it is today. And it would not really solve the problem of interop between, e.g., two different 3rd party libraries that expect different pointer types.

Having a single unified pointer type increases compatibility between code of diverse origins, though of course that comes at a price.


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
November 16
On Tuesday, 16 November 2021 at 18:25:53 UTC, H. S. Teoh wrote:
> On Tue, Nov 16, 2021 at 06:17:29PM +0000, Rumbu via Digitalmars-d wrote: [...]
>> In this new light, even I am not bothered by, I must admit that the garbage collector became something that doesn't fit in.
>> 
>> Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?
> [...]
>
> You can take the GC from me over my cold dead body.
>
>
> T

By accident I was actually reading this rn:
https://ocaml.org/learn/tutorials/garbage_collection.html
November 17

On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:

GC should be an option,not enforce on you.

November 16
On Wed, Nov 17, 2021 at 12:46:25AM +0000, zjh via Digitalmars-d wrote: [...]
> GC should be an option,not enforce on you.

IIRC the current GC doesn't even initialize itself on program startup until you make your first GC allocation.  So if main() is @nogc, you can pretty much already write an entire application without the GC starting up at all.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
November 17

On Wednesday, 17 November 2021 at 00:46:25 UTC, zjh wrote:

>

GC should be an option,not enforce on you.

D is originally a C like language.
If we can utilize the library of C/C++, what a big market ?

November 16
On Wed, Nov 17, 2021 at 12:58:42AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 17 November 2021 at 00:46:25 UTC, zjh wrote:
> 
> > GC should be an option,not enforce on you.
> 
> D is originally a `C like` language.
> If we can utilize the library of `C/C++`, what a big market ?

We already can.  I have many projects that call C libraries (not so much C++ because of incompatibilities between C++ and D templates), and it works fine.


T

-- 
Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11