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.
- Re: What is the D plan's to become a used ... Bienlein via Digitalmars-d
-
