On Wed, 2014-04-16 at 16:06 +0200, Sönke Ludwig via Digitalmars-d wrote: […] > > I agree, but I also wonder why you still keep ignoring vibe.d. It > achieves exactly that - right now! Integration with std.concurrency > would be great, but at least for now it has an API compatible > replacement that can be merged later when Sean's pull request is done.
Vibe.d is a single-thread event system, which is great (*) for the sort of problems Node.js, Vert.x, Tornado, Flask, Sinatra, Ratpack are used for. The point here is that CSP and dataflow are a concurrency and parallelism model that D has not got. std.concurrency is a heavyweight thread system so not really useful except to build thread pools and fork-join infrastructure. (OK that is a gross oversimplification.) std.parallelism is a great beginning of data parallelism on a thread pool. It needs more work. The thread pool needs to be brought front and centre, as a separate thing usable by other modules. On this CSP, dataflow, actors, etc. can be built. Due to other commitments, not least leading a massive update of GPars, I cannot lead on working on D things. If however someone can drive, I will certainly contribute, along the lines as I did when David Simcha wrote std.parallelism – mostly as a tester and reviewer. This also raises the issue of the D infrastructure having an obvious and documented way for people to contribute to things like std.parallelism. Whatever the truth, the perception is that to work on something like std.parallelism, you have to fork the whole of Phobos. In fact, std.parallelism is a single file 4,500 lines long (**). (*) It would be even better if it supported mocking for unit tests ;-) (**) I am still not a fan of single files this big. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder