Bottom line re GC in D

[Adrian via Digitalmars-d]

> Have you written enough D code where you have seen the current 
> GC is not good enough for you? How much good has to be the D GC 
> for you to use it?
>
> Bye,
> bearophile

Hi,

As I said at the start, I have been away a while but I wrote a 
fair amount of code in D about a year ago to test the waters.

 From my experience of those tests, I mainly targeted the GC and 
if I remember well, I had written code that, based on command 
line switches, specified if the incorporated GC is to be used for 
memory allocation/deallocation or whether memory is done entirely 
manually (I managed this through some posts in the forum where 
community members instructed me how to achieve this).

 From my limited tests, the ones which used manual memory 
management ran in roughly half the time; the GC ones took almost 
double the time and in some cases more than that. I don't have 
the code at hand (I might need to dig it out), but I certainly 
can vouch for a significant discrepancy in performance between 
the GC versions and manual versions. So yes, this is a 
significant issue (i.e. the current GC is not good enough for me 
and I cannot overlook it).

As for your second question (i.e. how good the GC needs to be for 
me), I would probably be satisfied with a GC that matches the 
Java one (used in conjunction with D's ability to take over 
memory management completely in the critical parts where needed) 
- but admittedly, I don't know the implications in achieving that 
within D's memory model, etc.

I am embarking on a start-up pretty soon and I have been looking 
at possible languages/frameworks to use; I've looked at Go in 
detail, had a cursory look (so far) at Rust and have also used to 
a fair degree. D is the most natural fit for me and my team 
coming from a mainly C++ and Java background, but I would really 
like to make an informed decision vis-a-vis the GC implications.

Thanks for your help.
- Adrian.