What are the worst parts of D?

[Dicebot via Digitalmars-d]

On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:
> On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via 
>> Digitalmars-d wrote:
>>> On Monday, 6 October 2014 at 16:06:04 UTC, Andrei 
>>> Alexandrescu wrote:
>> [...]
>>>> It would be terrific if Sociomantic would improve its 
>>>> communication
>>>> with the community about their experience with D and their 
>>>> needs
>>>> going forward.
>>>
>>> How about someone starts paying attention to what Don posts? 
>>> That
>>> could be an incredible start. I spend great deal of time both 
>>> reading
>>> this NG (to be aware of what comes next) and writing (to 
>>> express both
>>> personal and Sociomantic concerns) and have literally no idea 
>>> what can
>>> be done to make communication more clear.
>>
>> I don't remember who it was, but I'm pretty sure *somebody* at
>> Sociomantic has stated clearly their request recently: Please 
>> break our
>> code *now*, if it helps to fix language design issues, rather 
>> than
>> later.
>
> More particulars would be definitely welcome. I should add that 
> Sociomantic has an interesting position: it's a 100% D shop so 
> interoperability is not a concern for them, and they did their 
> own GC so GC-related improvements are unlikely to make a large 
> difference for them. So "C++ and GC" is likely not to be high 
> priority for them. -- Andrei

Yes and this is exactly why I am that concerned about recent 
memory management policy thread. Don has already stated it in his 
talks but I will repeat important points:

1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating 
garbage in a form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically 
lot of temporarily garbage allocations

This is a very simple issue that will prevent us from using and 
contributing to majority of Phobos even when D2 port is finished.

Switch to input/output ranges as API fundamentals was supposed to 
fix it. Custom management policies as you propose won't fix it at 
all because garbage will still be there, simply managed in a 
different way.

This is especially dissapointing because it was a first time when 
declared big effort seemed to help our needs but it got abandoned 
after very first attempts.