"Spawn as many thousand threads as you like" and D

[Russel Winder via Digitalmars-d]

On Wed, 2014-04-16 at 13:59 +0000, Bienlein via Digitalmars-d wrote:
> When looking at the success of Go it seems to me that it is 
> caused to a large extend by the kind of multi-threading Go offers 
> which is something like "spawn as many thousand threads as you 
> like".

A critically important thing here is the separation of goroutine and
thread, i.e. the concurrency and parallelism is about abstraction of the
programmers' expression and the underlying implementation — thread pool.
Go is not about multi-threading, it is about using goroutines and
programmers don't care about threads at all (to a third approximation). 

> Being able to spawn as many thousand threads as needed without 
> caring about it seems to be an important aspect for being an 
> interesting offering for developing server-side software. It 
> would be nice if D could also play in that niche. This could be 
> some killer domain for D beyond being a better C++.

Go does not spawn thousands of threads, see above :-)

C++11, and increasingly C++17 are making C++ into a totally different
language that 1980s C++ and C++99. It even has proposals for a
reasonable concurrency and parallelism layer over the now standardized
threads. Sadly though there are some really bad proposals being made to
the standards committee. C++ is suffering from the fact that people with
the right ideas are not proposing them for C++. Anthony Williams, Roger
Orr, Jonathan Wakeley and others are doing as good a job as they can
trying to make good stuff so there is some hope it will turn out well.
It is a great shame that the same effort is not going into improving D's
offerings here: D is in a far better position to do so much better that
C++ and what it has.

> While Go uses channels and goroutines D takes some actor-style 
> approach when spawning threads. This is also fine, but the 
> problems remains that you cannot create as many D kernel threads 
> just as you like. Maybe this could be something to improve in D 
> and promote in order to give D a further boost. I don't mean to 
> be pushy, it's just about exchanging ideas ;-). The 
> FiberScheduler by Sean Kelly could achieve something in that 
> direction. What do you think?

Go doesn't spawn threads, see above :-)

D would be significantly improved for a CSP implementation (which is
what goroutines and channels realize). Also a fork-join framework would
be a useful addition.

The problem is resource. Vibe.d, std.parallelism, std.concurrency
provide some tools but for CSP and dataflow, no-one has scratched the
itch.  I had been intending to do one project with D and GtkD, but ended
up switching to Go + QML because it was easier to do that than write a
CSP system for D.  For another C++ and Gtk project, it is easier to wait
for early C++17 implementations than it is to port the code to D (*).


(*) There is an element of "how many programmers risk" here not just
technical one. There are many more C++ programmers around who can use
new C++ style and features than there are D programmers. 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder