Deterministic Memory Management With Standard Library Progress

[Anthony via Digitalmars-d]

On Sunday, 5 March 2017 at 00:44:26 UTC, cym13 wrote:
> On Sunday, 5 March 2017 at 00:06:04 UTC, Inquie wrote:
>>> Finally GC problems are completely exagerated. It only runs 
>>> when used so having it to manage exceptions only for example 
>>> is completely viable, and it is possible to dereference 
>>> threads if you don't want them to be seen by the GC. Using GC 
>>> globally and avoiding it locally on heat points has proved to 
>>> be a successful strategy within the community. So I wouldn't 
>>> worry too much, giving it a try is paramount.
>>
>> Please stop making this argument. Just because one can 
>> amortize out the effect of the GC does not in any way change 
>> the fact that it is a stop the world GC and for certain 
>> applications this is provably a show stopper. One can come up 
>> with any number of commercial apps that fail using D's GC. 
>> Some applications require near real time behavior and D's GC 
>> does not provide any bounds on how long it runs... regardless 
>> of any average behavior(as that is meaningless when it only 
>> takes once to kill a person, create an audio glitch, etc). All 
>> these apps work fine with deterministic memory management or 
>> possibly other methods, but not D's GC.
>>
>> It is not a viable solution just because it is a solution for 
>> you. When you start writing these apps that simply do not 
>> function to the standards set by the customer and this is all 
>> due to D's GC, then you will experience why it is bad. Until 
>> then, you won't have a clue.
>>
>> It doesn't matter if it works 99.99% of the time, with these 
>> applications that may run for months at a time and have 
>> critical behavior constraints, 99.99% doesn't look that great. 
>> So, please don't push your ideals, motivations, experiences on 
>> others and just be honest with them. D's GC sucks for near 
>> real time applications, and it has problems. It one avoids the 
>> GC as best as they can using traditional techniques, it 
>> minimizes the effect of the GC and makes the app closer to 
>> real time.
>
> I completely agree that there are cases where having the GC is 
> a no-go and have even seen a number of projects doing fine 
> without it. But exactly as you say, just because it is a 
> problem for you doesn't mean it's a problem for everyone. 
> Clearly the OP hasn't tried D yet so as far as I'm concerned it 
> looks like his concern about GC come from critics he may have 
> read elsewhere and not from an actual case that makes GC 
> impossible to use. Given that I feel like conforting the fact 
> that, indeed, it works great for most applications.

I've learned the basics of D. I read the tutorial book, as I 
would call it, and some further tutorials on templates and other 
cool things. I just don't feel comfortable investing a 
significant effort acquainting myself further with the language 
without some guarantee that the feature will be completely 
supported eventually.

In a way, I'm picking a tool for my toolbelt, and C++ and D are 
competing tools. D looks like C++ 2.0, but it's missing a 
critical function of it as well. So, I'm conflicted.

I plan on answering the other answers, by the way. I just figured 
I'd wait a day or so to digest all the feedback together. But I 
do appreciate the effort from everyone so far, regardless of 
disagreements.