Garbage Collector

[cym13 via Digitalmars-d]

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
> On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:
>
>> They're not acceptable for a systems programming language as 
>> they require you to pay for something that you might not use.
>>
>> According to our resident GC maintainer (among many other 
>> things), they would cause a 1%-5% slow down in the language: 
>> https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
>
> Well I’m not sure about the 5% (MS says their write barrier 
> overhead is comparable to the cost of a simple method call, 
> namely 6.4ns: 
> https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
> yeah, there’s some tradeoff, for having a good GC.
>
> By the way, Go implemented those barriers in version 1.5 a year 
> ago: https://blog.golang.org/go15gc

May I point out that you do not seem to have any kind of 
experience
of D's GC? Try it and see for yourself wether it actually stops 
you
or not. It's right that not everyone is pleased with the current 
GC
but those users have specific expectations and I'm not certain at
all that they would find C# or Go's GC acceptable either.

The point is, D doesn't have to have a GC. Not using it is way 
easier
than in most other languages because all the tools to help you
profile it and avoid it are provided by the compiler. Go without a
good GC is a dead language. D without a good GC is just not as 
good
as it could be. And btw we're generally faster than Go ;-)

The point is: while a better GC is a work in progress we'll 
*never*
have a GC that can fit all needs, but it's not as critical as it 
is
in Go or in C# because we provide other ways to manage memory when
limitations arise.