Where will D sit in the web service space?

[via Digitalmars-d]

On Monday, 13 July 2015 at 15:58:03 UTC, Faux Amis wrote:
> On Mon 13/07/2015 16:58, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>> On Monday, 13 July 2015 at 12:39:51 UTC, Faux Amis wrote:
>>> To me the GC is there for prototyping anf the moment we have
>>> performance issues we can strip out the lacking parts.
>>
>> So in essence you think of D taking a position closer to 
>> Rust/C++ than
>> Go/Java.
> Sadly, I have insignificant experience with Rust and Go.
> Nowadays I am doing mostly frontend js.
>
> Not sure on which aspects I should position D; use case, usage?

The way I see it:

For a typical web service I usually want convenience and low 
development time. Meaning, I want automatic garbage collection 
(like GC), but I also want low latency so that clients can hammer 
the server requesting resources without significant delays. So 
the Go 1.5 GC seems suitable.

For a demanding functionality-limited web service (like image 
processing) I might want to conserve memory and avoid 
collections, but I also want to avoid issues like memory leaks.

If the D GC isn't good enough for typical web services it seem 
like D will be limited to the more narrow non-GC web services 
where high performance/low memory usage is important.

So Go/Java basically will take the big slice of the pie because 
they have low latency GCs, and C++/Rust/D takes the small slice? 
(Assuming that manual memory management is less convenient and 
takes more developer time.)