Jump to page: 1 214  
Page
Thread overview
Future of memory management in D
Nov 16, 2021
Rumbu
Nov 16, 2021
H. S. Teoh
Nov 16, 2021
Imperatorn
Nov 16, 2021
Imperatorn
Nov 16, 2021
IGotD-
Nov 16, 2021
H. S. Teoh
Nov 17, 2021
jmh530
Nov 17, 2021
Paulo Pinto
Nov 17, 2021
IGotD-
Nov 17, 2021
Paulo Pinto
Nov 17, 2021
jmh530
Nov 17, 2021
zjh
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
zjh
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
Guillaume Piolat
Nov 17, 2021
zjh
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
zjh
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
zjh
Nov 17, 2021
zjh
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
zjh
Nov 17, 2021
SealabJaster
Nov 17, 2021
zjh
Nov 17, 2021
bachmeier
Nov 17, 2021
zjh
Nov 17, 2021
forkit
Nov 17, 2021
zjh
Nov 17, 2021
russhy
Nov 17, 2021
Imperatorn
Nov 17, 2021
Stanislav Blinov
Nov 17, 2021
Imperatorn
Nov 17, 2021
Stanislav Blinov
Nov 17, 2021
Tejas
Nov 17, 2021
Stanislav Blinov
Nov 17, 2021
Tejas
Nov 17, 2021
Commander Zot
Nov 17, 2021
tchaloupka
Nov 17, 2021
Adam D Ruppe
Nov 17, 2021
Adam D Ruppe
Nov 17, 2021
Imperatorn
Nov 17, 2021
Imperatorn
Nov 17, 2021
tchaloupka
Nov 17, 2021
SealabJaster
Nov 17, 2021
SealabJaster
Nov 17, 2021
tchaloupka
Nov 17, 2021
Zoadian
Nov 17, 2021
Imperatorn
Nov 17, 2021
Greg Strong
Nov 17, 2021
bachmeier
Nov 18, 2021
bachmeier
Nov 18, 2021
Atila Neves
Nov 18, 2021
JN
Nov 17, 2021
Stanislav Blinov
Nov 17, 2021
Alexandru Ermicioi
Nov 18, 2021
zjh
Nov 17, 2021
forkit
Nov 17, 2021
H. S. Teoh
Nov 17, 2021
forkit
Nov 17, 2021
Paulo Pinto
Nov 17, 2021
forkit
Nov 17, 2021
Paulo Pinto
Nov 17, 2021
Tejas
Nov 17, 2021
Atila Neves
Nov 18, 2021
Atila Neves
Nov 18, 2021
rumbu
Nov 18, 2021
forkit
Nov 18, 2021
rumbu
Nov 18, 2021
Nick Treleaven
Nov 18, 2021
Rumbu
Nov 18, 2021
Rumbu
Nov 18, 2021
Adam D Ruppe
Nov 18, 2021
Adam D Ruppe
Nov 18, 2021
Tejas
Nov 18, 2021
Atila Neves
Nov 18, 2021
Imperatorn
Nov 18, 2021
rumbu
Nov 18, 2021
JN
Nov 18, 2021
Rumbu
Nov 18, 2021
H. S. Teoh
Nov 18, 2021
Atila Neves
Nov 19, 2021
Max Samukha
Nov 19, 2021
Dom DiSc
Nov 19, 2021
Dom DiSc
Nov 19, 2021
Alexandru Ermicioi
Nov 19, 2021
12345swordy
Nov 19, 2021
Timon Gehr
Nov 19, 2021
Timon Gehr
Nov 19, 2021
Alexandru Ermicioi
Nov 19, 2021
Alexandru Ermicioi
Nov 19, 2021
rumbu
Nov 20, 2021
Dom DiSc
Nov 20, 2021
Rumbu
Nov 20, 2021
Commander Zot
Nov 20, 2021
Rumbu
Nov 20, 2021
Commander Zot
Nov 19, 2021
12345swordy
Nov 20, 2021
Atila Neves
Nov 20, 2021
12345swordy
Nov 21, 2021
Max Samukha
Nov 23, 2021
russhy
Nov 18, 2021
Atila Neves
November 16, 2021

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, 2021
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, 2021
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, 2021

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, 2021
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, 2021
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, 2021

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

GC should be an option,not enforce on you.

November 16, 2021
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, 2021

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, 2021
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