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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
