GCs in the news

[Chris via Digitalmars-d]

On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
>> On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
>>> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
>>> Digitalmars-d wrote:
>>>> It appears still to be a general meme that performance 
>>>> required no GC
>>>> and GC mean poor performance. The debate has been restarted 
>>>> on the Go
>>>> mailing list under the banner "go without garbage 
>>>> collector". The
>>>> response to will Go remove the garbage collector was somewhat
>>>> unequivocal: nope.
>>>
>>> That's good news in a way. If a big company accepts GC and 
>>> the Go crowd go with it (pardon the pun), then it will find 
>>> more acceptance (as Paulo pointed out in a different thread).
>>
>> It's not about "acceptance", it's about the reality that a GC 
>> is not a universal solution to memory management.
>
> Point taken. But as has been said before 90-95% of all apps can 
> live happily with GC, and if you want, you can still go bare 
> metal with D. The security GC offers should not be 
> underestimated either. With "acceptance" I meant that people 
> see "it cannot be that bad after all for *most* applications". 
> The GC issue is often cited as a D-eal breaker. I understand 
> that there are applications that need total control over the 
> memory. But those apps have always been programmed in C or any 
> other close-to-the-machine language, and even then programmers 
> (in gaming for example) have to use additional tricks and hacks 
> to squeeze out every little bit of performance. What D has to 
> do is to facilitate control over the memory, but I still 
> consider it a systems programming language due to the fact that 
> it has many things to offer as regard the direct interaction 
> with the machine that Java and C# don't. Can you write a device 
> drive in Java, if yes, tell me how, I'm interested.
>
>> Just from watching a few of the DConf 2014 talks, if you want 
>> performance you avoid the GC at all costs (even if that means 
>> allocating into huge predefined buffers). Once you're going to 
>> these lengths to avoid garbage collection it begs the 
>> question, why are you even using this language? Within this 
>> community the question is rhetorical but to outsiders I feel 
>> it's a major concern.
>
> Don't know if it's really a "major concern" or the favorite 
> weak spot that C++ et. al guys like to flog to death in order 
> to distract from the many strengths that D has (in comparison 
> with C++ et al.) The answer is always "D has GC, it's the 
> Devil, don't touch it!" Also, let's put a little faith in the 
> brilliant developers behind D, I'm sure there's a huge 
> performance boost for D around the corner.

Ah, and there's inline asm too!