https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non gc version in the future...

On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
> 
> It seems that D still has the GC being mentioned up to today.
> 
> Maybe its better to move the standard library slower to a non gc version in the future...

Why is GC a problem?


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
> On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
>> https://www.quora.com/What-is-your-review-of-D-programming-language
>> 
>> It seems that D still has the GC being mentioned up to today.
>> 
>> Maybe its better to move the standard library slower to a non gc version in the future...
>
> Why is GC a problem?
>
>
> T

The reputation is D's GC is slow, and Manual Memory Management is fast

On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
> > On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
> > > https://www.quora.com/What-is-your-review-of-D-programming-language
> > > 
> > > It seems that D still has the GC being mentioned up to today.
> > > 
> > > Maybe its better to move the standard library slower to a non gc version in the future...
> > 
> > Why is GC a problem?
> > 
> > 
> > T
> 
> The reputation is D's GC is slow, and Manual Memory Management is fast

The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.  But there's not much you can say to GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one of them.)


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.

On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
> On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d wrote:
>> On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
>> > On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
>> > > https://www.quora.com/What-is-your-review-of-D-programming-language
>> > > 
>> > > It seems that D still has the GC being mentioned up to today.
>> > > 
>> > > Maybe its better to move the standard library slower to a non gc version in the future...
>> > 
>> > Why is GC a problem?
>> > 
>> > 
>> > T
>> 
>> The reputation is D's GC is slow, and Manual Memory Management is fast
>
> The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.  But there's not much you can say to GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one of them.)
>
>
> T

For me the important point is not directly about performance, but about determinism.
I know when the GC is called, and i can set when to collect, but I have no idea what they will do, how much memory they will free nor the time they will spent doing it. And this lack of control is the true problem.

On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc version in the future...

D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting.

We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; @nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense.

Honestly, I would _hate_ to use D without a GC. Without it, @safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of @trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory.

That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed).

Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC.

- Jonathan M Davis

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:

> Why is GC a problem?
>
>
> T


--
> **** Everybody talks about it, but nobody does anything about it!  -- Mark Twain**

Are you sure your quotes are randomly generated ??

Jonathan Davis wrote:
"We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons."

Perception is so important when people are making decisions about something they don't know.  (As Walter says, you have to write tens of sloc in a language to really see it's benefits.  They won't be so evident if you write D like the languages you know).

So I think the GC series has been very helpful.

But it might also be helpful to be very explicit on the functions that can and can't be called with nogc (I mean a top level overview in the docs) because it's one of the remaining sources of FUD that people say "yeah but you can't use large parts of the standard library without the GC".

And for things that are useful and easiest done with GC it would be nice to have an alternative that doesn't depend on the GC - if for no other reason than to address objections.  So the answer is then "yes - you're right, these X functions depend on the GC, but there are similar ones that don't".  (Walter already started that for functions that use the GC for purely legacy reasons but I mean for more difficult cases too.  I know Weka wrote their own versions of some std.algorithm functions for example).  Many things aren't much work, but when you have a lot to do, even small frictions can have big consequences.

So it's also a documentation question - it's not that easy from the outside last time I looked to see just how easy std.experimental.allocator is to use.

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting.
>
> We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; @nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense.
>
> Honestly, I would _hate_ to use D without a GC. Without it, @safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of @trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory.
>
> That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed).
>
> Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC.
>
> - Jonathan M Davis

The issue is only mentioned, because it keeps getting talked about ( mostly one sided ) on forums and sites like the above mentioned quora.com. Its hard to change people there perception, without counter arguing. Currently as i write this, these claims on quora are unchallenged.

I can make a few simple demos and have D use by default 5 to 10 more memory then the exact same C or C++ program. While D does not actually use it ( its only marked as allocated for the GC ), it does not dispel the notion or feeling of people that a GC = bad.

Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language. The Go developers have done a massive ( an impressive ) amount of work on trying to reduce GC pauses in the last two years, and that communication and effort has helped to reduce the GC myth ( for people looking at Go ).

Another part of the issue is, while D can be run without the GC, i can not tell what parts of the standard library can work without the GC. Even a simple output parsing gave me a compile error when running nogc a while ago.

When every new languages besides Rust or Zig are GC. That same "flaw" is not looked upon as a issue. It seems that D simply carries this GC stigma because the people mentioning are  C++ developers, the same people D targets as a potential user base.

D can have more success in targeting people from scripting languages like PHP, Ruby, Python, where the GC is not looked upon as a negative. The same effect can be seen in Go its popularity with drawing developers from scripting languages despite it not being there intention.

I always felt that D position itself as a higher language and in turn scares people away while at the same time the people it wants to attracts, with most are already set in there ways and looking at excuses to discredit D. The whole C++ has all of D features and does not need a GC / GC is bad excuse we see in the quora.com posting fits that description ( and not only there, also on other sites ).

If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> D's GC isn't going anywhere.

Well, if I got the message correctly, it seems the key Dlang maintainers, are more sold on adding full support to Deterministic (manual) Memory management

And a lot less sold on improving the existing GC

So as I understand the current road map involve more work on  Deterministic (manual) Memory management and a lot less work on improving the GC

And the requirement for the GC will be removed from the standard library

On Friday, October 06, 2017 21:39:21 Ali via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> > D's GC isn't going anywhere.
>
> Well, if I got the message correctly, it seems the key Dlang maintainers, are more sold on adding full support to Deterministic (manual) Memory management
>
> And a lot less sold on improving the existing GC
>
> So as I understand the current road map involve more work on Deterministic (manual) Memory management and a lot less work on improving the GC

There is definitely work being done towards improving more deterministic forms of memory management, but there's also been work done towards improving the GC. It just isn't talked about much.

And even some of the more deterministic memory management is still potentially going to be using the GC (e.g. they've talked about introducing better language support for reference counting but using the GC to take care of cycles).

> And the requirement for the GC will be removed from the standard library

Some parts of the standard library will always require the GC. Much of it does not. The idea is to avoid requiring the GC when it doesn't make sense to require the GC, and there are cases where the GC is accidentally required. For instance, on the whole, stuff like std.algorithm should not use the GC and does not use the GC, but sometimes, when lambdas get involved, closures end up being allocated, which means that the GC gets used, and that may not have been intended or expected. Some of that can be prevented, and some of it can't. Someone who wants to fully avoid the GC probably will need to minimize passing lambdas to functions and prefer functions or functors.

The main thing is that we need to ensure that the GC is not required when it's not meant to be required. It has never been the plan to remove it from Phobos completely. That really wouldn't make any sense, and in quite a few cases, it literally can't be done (e.g. a number of functions were designed to return newly allocated arrays; we can provide alternatives to them in a number of cases, but we couldn't make the existing stuff not use the GC).

So, plenty of work still needs to be done to ensure that some stuff is marked @nogc when it should be and ensure that the GC is not accidentally used, but we're not stripping out the GC.

In some cases, it probably is just figuring out a way to make the documentation clearer like Laeeth mentioned, but that can be a bit entertaining given that whether something allocates is frequently a question of what arguments it's given (e.g. very little in std.algorithm will ever allocate if it's given a functor, but lots of it will allocate if it's given a lambda or non-static nested function that the compiler decides might need a closure allocated), and that can't really be covered by @nogc in the documentation. You can use @nogc when you call it to ensure that you're not triggering the GC, but it depends on what you passed, so it has to be inferred rather than being explicitly documented as @nogc. And thus far, we really haven't done anything to figure out how to document when whether something uses the GC depends on what you pass it.

Regardless, I can absolutely guarantee that Walter and Andrei are not planning to rip the GC out of everything. They just don't want to be requiring it when we don't need to, and that's not something that Phobos has always done a good job of, though a lot of the idioms it uses seriously reduce GC usage.

- Jonathan M Davis