What is the D plan's to become a used language?

[Bienlein via Digitalmars-d]

>People have already suggested you to actually try vibe.d at 
>least once before repeating "CSP is necessary for easy async" 
>mantra.

I was trying to point out in some previous thread that the value 
of CSP is that concurrent things from the code looks like 
 >>sync<< calls (not async, but sync). The statement above again 
says async and not sync (in "CSP is necessary for easy async 
mantra."). So, I'm not sure the point was understood.

Asynchronous programming is very difficult to get right and also 
inherently difficult. Programming with channels where things look 
like >>synchronous calls<< make concurrent programming immensely 
easier than with asynchronous programming. If you have done 
asynchronous programming for some years and then only spend 1/2 h 
looking at concurrency in Go you will grasp immediately that this 
is a lot lot simpler. All cores are being made used of very 
evenly out of the box and are constantly under high load. You 
have to work very hard for long time to achieve the same in 
Java/C/C++/C#/whatever, because the threading model is 
conventional. With CSP-style concurrency in Go it is a lot easier 
to write concurrent server side applications and whatever you do 
can hold 40'000 network connections out of the box. Yes, you can 
do that with vibe.d as well. But for Go you only need to learn a 
drop simple language and you can start writing your server 
application, because all you need for concurrency is in the 
language.

One idea would be to add a drop dead simple abstraction layer for 
vibe.d to provide the same and sell D as a language for server 
side development like Go. There is a need for a unique selling 
point. Let's say the guys at Docker had chosen D, because it had 
that already. Then they would realize that they also can use D 
for general purpose programming and be happy. But first there has 
to be a unique selling point. The selling point of a better C++ 
has not worked out. You have to accept that and move on. Not 
accepting that time moves on is not an option.

>Sorry, but wrong and wrong. Go has a model of concurrency and 
>parallelism that works very well and no other language has, so 
>Go has technical merit.

The technical merit is in the concurrency model as already said 
in the statement above. And currently is the time of server side 
software development. When C++ was started it was time for some 
better C. That time is over. Things change constantly and there 
is nothing you can do about that. You can accept that things have 
moved on and make use of the new chance of server side 
programming as a new selling point or continue living in the 
past. Go might be simplistic. So add CSP-style channels to D and 
you can overtake Go in all respects very easily. Besides, Haskell 
also has channel-based inter-process communication. If that is 
not academical/scientiic backing then I don't know.