Where will D sit in the web service space?

[rsw0x via Digitalmars-d]

On Monday, 13 July 2015 at 16:24:07 UTC, Ola Fosheim Grøstad 
wrote:
> 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:
>>> [...]
>> 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.)

*BSD and OSX could have a good concurrent GC implementation on D. 
When the Linux kernel devs feel like pulling their heads out of 
their asses and provide developers with useful VM APIs, it could 
too.

I plan on discussing this in a blog post if anyone cares.