At least on Internet forums, there seems to be an entire category of people dismissing D immediately because it has a GC.

http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccne46t
http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnddqd
http://www.reddit.com/r/programming/comments/1nsxaa/when_performance_matters_comparing_c_and_go/cclqbqw

The subject inevitably comes in every reddit thread like it was some kind of show-stopper.

Now I know first-hand how much work avoiding a GC can give (http://blog.gamesfrommars.fr/2011/01/25/optimizing-crajsh-part-2-2/).

Yet with D the situation is different and I feel that criticism is way overblown:
- first of all, few people will have problems with GC in D at all
- then minimizing allocations can usually solve most of the problems
- if it's still a problem, the GC can be completely disabled, relevant language features avoided, and there will be no GC pause
- this work of avoiding allocations would happen anyway in a C++ codebase
- I happen to have a job with some hardcore optimized C++ codebase and couldn't care less that a GC would run provided there is a way to minimize GC usage (and there is)

Whatever rational rebutal we have it's never heard.
The long answer is that it's not a real problem. But it seems people want a short answer. It's also an annoying fight to have since so much of it is based on zero data.

Is there a plan to have a standard counter-attack to that kind of overblown problems?
It could be just a solid blog post or a @nogc feature.

Whereas I'm right now with more time than money, I've been thinking about doing a kickstarter or something with the goal of doing the necessary changes to make going without the gc easy:

1) make sure all allocations in phobos are explicit and avoidable where possible
2) have a flag where you can make gc allocations throw an assert error at runtime for debugging critical sections
3) maybe the @nogc thing people are talking about

and whatever else comes up.


While I tend to agree that the gc arguments don't carry much water (much bigger problem IMO is how intertwined phobos is... and even that is meh much of the time), having all this set up would be nice slam counter argument: the stdlib does not require the gc and there's ways to avoid it pretty easily.


The downside I expect with the kickstarter thing though is most the people complaining about this probably aren't willing to pitch in cash - they have little to gain from it since they aren't D users already. But it'd still be interesting to try.

On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
> Whatever rational rebutal we have it's never heard.
> The long answer is that it's not a real problem. But it seems people want a short answer. It's also an annoying fight to have since so much of it is based on zero data.

Do not forget the followup: Without GC you cannot use the standard library.

I am not sure if there is a really good counter. Some people think that a GC will never ever be possible in their domain. Either they are right or no rational argument will help. Only a small percentage will read the reasonable long argumentation.

Maybe a killer app: Something hard realtime and high performance packed into a commercially successful product of a well known company.

Adam D. Ruppe:

> 3) maybe the @nogc thing people are talking about

Some people have even suggested to support @nogc or @noheap as module attributes (beside being usable as function attributes).

Bye,
bearophile

On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
> Yet with D the situation is different and I feel that criticism is way overblown:
> - first of all, few people will have problems with GC in D at all
> - then minimizing allocations can usually solve most of the problems
> - if it's still a problem, the GC can be completely disabled, relevant language features avoided, and there will be no GC pause
> - this work of avoiding allocations would happen anyway in a C++ codebase
> - I happen to have a job with some hardcore optimized C++ codebase and couldn't care less that a GC would run provided there is a way to minimize GC usage (and there is)
>
> Whatever rational rebutal we have it's never heard.
> The long answer is that it's not a real problem. But it seems people want a short answer. It's also an annoying fight to have since so much of it is based on zero data.
>
> Is there a plan to have a standard counter-attack to that kind of overblown problems?
> It could be just a solid blog post or a @nogc feature.

i have never bothered about D GC(nor C# or others implementations), maybe that's just because i don't have that high memory/performance constraints, but still i definitely would start with GC and then work for minimize allocations... just because it allows focus on code more than memory management, and thus should give much better productivity and quality.

On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe wrote:
> 2) have a flag where you can make gc allocations throw an assert error at runtime for debugging critical sections

Why handle it at runtime and not at compile time?

Am 08.10.2013 17:55, schrieb qznc:
> On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
>> Whatever rational rebutal we have it's never heard.
>> The long answer is that it's not a real problem. But it seems people
>> want a short answer. It's also an annoying fight to have since so much
>> of it is based on zero data.
>
> Do not forget the followup: Without GC you cannot use the standard library.
>
> I am not sure if there is a really good counter. Some people think that
> a GC will never ever be possible in their domain. Either they are right
> or no rational argument will help. Only a small percentage will read the
> reasonable long argumentation.
>
> Maybe a killer app: Something hard realtime and high performance packed
> into a commercially successful product of a well known company.

Having been an user of the Native Oberon OS in the 90's, I tend to think it is more of a mental barrier than everything else.

That said, in Oberon it is easier to control garbage than in D, as all GC related allocation are done via NEW or string manipulations, there are no implicit allocations. Manual memory management is also available via the SYSTEM module.

--
Paulo

On Tuesday, 8 October 2013 at 16:02:05 UTC, Tourist wrote:
> On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe wrote:
>> 2) have a flag where you can make gc allocations throw an assert error at runtime for debugging critical sections
>
> Why handle it at runtime and not at compile time?

One is I can implement a runtime check pretty easily so it'd just be the first step because it would go quickly.

The other reason though would be D doesn't really have an attributed section. You can't do:

void foo() {
   // stuff
   @nogc {
      // your performance sensitive loop code
   }
}

But on the function level, that could be done at compile time if implemented.

On Tuesday, 8 October 2013 at 16:18:50 UTC, Adam D. Ruppe wrote:
> On Tuesday, 8 October 2013 at 16:02:05 UTC, Tourist wrote:
>> On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe wrote:
>>> 2) have a flag where you can make gc allocations throw an assert error at runtime for debugging critical sections
>>
>> Why handle it at runtime and not at compile time?
>
> One is I can implement a runtime check pretty easily so it'd just be the first step because it would go quickly.
>
> The other reason though would be D doesn't really have an attributed section. You can't do:
>
> void foo() {
>    // stuff
>    @nogc {
>       // your performance sensitive loop code
>    }
> }
>
> But on the function level, that could be done at compile time if implemented.

IMO it would be much more effective if it would be handled at compile time, both saving the dev's time and guaranteeing that there are no unwanted assert(0)'s lurking around in untested corners.

On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
> Is there a plan to have a standard counter-attack to that kind of overblown problems?
> It could be just a solid blog post or a @nogc feature.

It is not overblown. It is simply "@nogc" which is lacking but absolutely mandatory. Amount of hidden language allocations makes manually cleaning code of those via runtime asserts completely unreasonable for real project.