A few days ago i was reading this topic:

https://news.ycombinator.com/item?id=14165198

And the whole GC keeps coming up as a negative ( compared to Rust ).

From my understanding there has been a proposal DIP1000 to address this issue. Is there any update on this topic?

Is it possible to run D without the GC AND the standard library?

On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote:
> A few days ago i was reading this topic:
>
> https://news.ycombinator.com/item?id=14165198
>
> And the whole GC keeps coming up as a negative ( compared to Rust ).

That's subjective, at best.
I see most of Rust's ownership mechanics in a negative light (love the lisp-inspired syntax, though), as they incur a severe productivity decrease while providing little safety benefit for /me/ over what I already have in D. But, as always, YMMV.

>
> From my understanding there has been a proposal DIP1000 to address this issue.

You'll have to be more specific about what issue you're referring to. People not liking garbage collection? In any case, AFAIU DIP1000 was about more mechanically verifiable memory safety features when not using the GC.

>
> Is it possible to run D without the GC AND the standard library?

It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics)

[1] http://forum.dlang.org/thread/occ9kk$24va$1@digitalmars.com

On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote:
> A few days ago i was reading this topic:
>
> https://news.ycombinator.com/item?id=14165198
>
> And the whole GC keeps coming up as a negative ( compared to Rust ).
>
> From my understanding there has been a proposal DIP1000 to address this issue. Is there any update on this topic?
>
> Is it possible to run D without the GC AND the standard library?

You might find this blog post relevant:
http://dlang.org/blog/2017/03/20/dont-fear-the-reaper/

There is opposition to the GC from a small but vocal group of mostly C++ developers. Sometimes they even make valid arguments. You can find many threads on the topic here.

On Thursday, 27 April 2017 at 16:35:57 UTC, Moritz Maxeiner wrote:
> You'll have to be more specific about what issue you're referring to. People not liking garbage collection? In any case, AFAIU DIP1000 was about more mechanically verifiable memory safety features when not using the GC.
>
>>
>> Is it possible to run D without the GC AND the standard library?
>
> It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics)
>
> [1] http://forum.dlang.org/thread/occ9kk$24va$1@digitalmars.com

Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient.

Been thinking about this topic. Dlang has a destructor, does that means if you allocate on the GC and then do your own destructor, it technically counts as manual memory management?

That is assuming the GC removes the memory reference when you call it. I remember seeing in some other languages ( C# possibly? ) that referring a variable to be freed only meant the GC freed the memory when it felt like it, not the exact spot when you told it.

I personally think that people simple have a bad taste with GC because they kick in too much outside there control. For 90% the default behavior is good but its those 10% that leaves a bad taste with people ( GC on critical moments and hurting performance in return ).

On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
> Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient.

You can easily disable automatic collections and trigger one manually:

----
import core.memory: GC;
GC.disable(); /* disable automatic collections */
/* ... do your loop ... */
GC.collect(); /* manually trigger collection */
GC.enable(); /* enable automatic collections */
----

> Been thinking about this topic. Dlang has a destructor, does that means if you allocate on the GC and then do your own destructor, it technically counts as manual memory management?

I'm not sure what role the destructor supposedly plays here. A destructor is called automatically when the object is freed, or you can call it manually with `object.destroy` [1]. Freeing happens when the object is collected, or you can use `core.memory.GC.free` [2] to free without collecting. Collecting happens automatically, or you can trigger it with `core.memory.GC.collect` [3] as shown.

You can use a destructor to manage memory owned by the object. But the destructor being there doesn't affect how the object itself is managed.

> That is assuming the GC removes the memory reference when you call it. I remember seeing in some other languages ( C# possibly? ) that referring a variable to be freed only meant the GC freed the memory when it felt like it, not the exact spot when you told it.

Destroying does not imply freeing. It's the other way around. If you want to free, call `GC.free`. That does count as manual memory management.

> I personally think that people simple have a bad taste with GC because they kick in too much outside there control. For 90% the default behavior is good but its those 10% that leaves a bad taste with people ( GC on critical moments and hurting performance in return ).

You can:

1) Call `core.memory.GC.disable` [4] if you don't want the GC to collect for a while. You should make sure that you don't run out of memory during that time, of course. Use `core.memory.GC.enable` [5] to enable collections again.

2) Use the `@nogc` [6] attribute to forbid GC allocations in a function. GC collections are only triggered by allocations (or manually). So the GC won't kick in during execution of @nogc code.



[1] https://dlang.org/phobos/object.html#.destroy
[2] https://dlang.org/phobos/core_memory.html#.GC.free
[3] https://dlang.org/phobos/core_memory.html#.GC.collect
[4] https://dlang.org/phobos/core_memory.html#.GC.disable
[5] https://dlang.org/phobos/core_memory.html#.GC.enable
[6] https://dlang.org/spec/attribute.html#nogc

GC it´s not only about some performance issues that some people may encounter on D, but it its a marketing problem as well.

"D is a systems programming language with..." GC(!?).

Most people that are interest in D came from c/c++ or other backgrounds without GC or hearing their entire life that GC "may be bad".

Its not a question of "how bad it is" or if it is bad at all.

People know how to program without GC. So this is just something in the way.

Anyway D is awesome.

On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
> On Thursday, 27 April 2017 at 16:35:57 UTC, Moritz Maxeiner wrote:
>> You'll have to be more specific about what issue you're referring to. People not liking garbage collection? In any case, AFAIU DIP1000 was about more mechanically verifiable memory safety features when not using the GC.
>>
>>>
>>> Is it possible to run D without the GC AND the standard library?
>>
>> It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics)
>>
>> [1] http://forum.dlang.org/thread/occ9kk$24va$1@digitalmars.com
>
> Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient.

You replied to the wrong person here, seeing as I did not link to the article you're referring to, but your statement about not being efficient is, honestly, ludicrous, so I'll reply:
Expanding the continuous memory region a dynamic array consists of (possibly moving it) once it overflows has absolutely nothing to do with the GC, or even the language, it's how the abstract data type "dynamic array" is defined. D just does this transparently for you by default. If you already know the exact or maximum size, you can allocate *once* (not 6 times) using `new` and `.reserve` respectively *before* entering the loop, like that article explains in depth.

>
> Been thinking about this topic. Dlang has a destructor, does that means if you allocate on the GC and then do your own destructor, it technically counts as manual memory management?

Um, what? Memory (de)allocation (in C often malloc/free) and object (de)contruction (in C usually functions with some naming conventions like `type_init`/`type_deinit`) are on two entirely different layers! Granted, they are often combined in C to functions with names like `type_new`/`type_free`, but they are conceptually two distinct things. Just to be very clear, here is a primitive diagram of how things work:
make object O of type T:
<OS> --(allocate N bytes)--> [memory chunk M] --(call constructor T(args) on M)--> [O]
dispose of O:
[O] --(call destructor ~T() on O)--> [memory chunk M] --(deallocate M)--> <OS>

D's garbage collector conceptually changes this to:
make object O of type T:
<OS> --(GC allocates)--> [GC memory pool] --(allocate N bytes)--> [memory chunk M] --(call constructor T(args) on M)--> [O]
dispose of O:
[O] --(call destructor ~T() on O)--> [memory chunk M] --(deallocate M)--> [GC memory pool] --(GC deallocates)--> <OS>
with the specific restriction that you have *no* control over 'GC deallocates' and only indirect control over 'GC allocates' (by allocating more memory from the GC than is available its the pool).

Working on the memory chunk layer is memory management.
Working on the object layer is object lifetime management.
D offers you both automatic memory management and automatic lifetime management via its GC.
What you describe is manual object lifetime management (which is what std.conv.emplace and object.destroy exist for) and has no effect on the automatic memory management the GC performs.
You *can* do manual memory management *on top* of the GC's memory pool (using core.memory.GC.{alloc/free) or the newer, generic Alloactor interface via std.experimental.allocator.gc_allocator.GCAllocator.{allocate/deallocate}), but these operations will (generally) not yield any observable difference from the OS's perspective.

>
> That is assuming the GC removes the memory reference when you call it. I remember seeing in some other languages ( C# possibly? ) that referring a variable to be freed only meant the GC freed the memory when it felt like it, not the exact spot when you told it.

Again, you seem to mix object lifetime management and memory management. You cannot tell the GC to free memory back to the operating system (which is what the free syscall does and what you seem to be describing). You can *only* free memory you allocated *from* the GC *back* to the GC. The GC decides when (and if) any memory is ever being freed back to the OS (which is kinda one major point of having a GC in the first place).

>
> I personally think that people simple have a bad taste with GC because they kick in too much outside there control.

In my experience most people's aversion to GCs can be aptly described by the German proverb "Was der Bauer nicht kennt, das frisst er nicht" (the meaning of which being that most people generally like living in comfort zones and rarely - if ever - dare to leave them of their own free will; that includes developers, sadly).

> For 90% the default behavior is good but its those 10% that leaves a bad taste with people ( GC on critical moments and hurting performance in return ).

Then don't allocate using the GC in such critical pieces of code? If you want automatic verification, annotate a function with @nogc (also works with anonymous functions, lambdas, etc); just be aware that not everything in druntime and phobos that could (and should) be annotated currently is (if you encounter any such functions, open a bug report for it so it can be fixed).

On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
>
> Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop.

Please reread that bit.

"there were six total GC allocations in the loop. That means there were six opportunities for the GC to collect garbage."

Keyword: opportunities. There were six allocations, not six collections. The GC only "kicks in" when it needs to reclaim memory. In this case, the six allocations are made by the array management in DRuntime. It's the same as you allocating with `new` six times. In all of those cases, as long as the GC has room in its pool from which to allocate, there will be no collections.

Preallocate as much as possible and minimize the number of GC allocations (allocate on the stack where possible and through malloc where necessary) and the GC is not going to get in the way for most D programs you write.

On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner wrote:
> Working on the memory chunk layer is memory management.
> Working on the object layer is object lifetime management.
> D offers you both automatic memory management and automatic lifetime management via its GC.

D offers sound automatic lifetime management? Since when?

On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
> Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient.

 I find myself trying to use the stack as much as possible for buffers and structs so i can control and throw them away properly without worrying about the GC. The downside is they have to be fairly small (at least under windows without forcing it using a new thread or fiber).