On Monday, 4 August 2014 at 21:19:14 UTC, Philippe Sigaud via Digitalmars-d-learn wrote:
> Has anyone used (the fiber/taks of) vibe.d for something other than
> powering websites?

Atila has implemented MQRR broker with it : https://github.com/atilaneves/mqtt
It it still networking application though - I don't know of any pure offline usage.

On Monday, 4 August 2014 at 21:19:14 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
>
> Has anyone used (the fiber/taks of) vibe.d for something other than powering websites?

https://github.com/D-Programming-Language/phobos/pull/1910

> https://github.com/D-Programming-Language/phobos/pull/1910

Very interesting discussion, thanks. I'm impressed by the amount of work you guys do on github.

On Mon, 2014-08-04 at 18:34 +0000, Dicebot via Digitalmars-d-learn
wrote:
[…]
> Well it is a territory not completely alien to me either ;) I am less aware of academia research on topic though, just happen to work in industry where it matters.

I have been out of academia now for 14 years, but tracking the various lists and blogs, not to mention SuperComputing conferences, there is very little new stuff, the last 10 has been about improving. The one new thing is though GPGPU, which started out as an interesting side show but has now come front and centre for data parallelism.

> I think initial spread of multi-threading approach has happened because it was so temptingly easy - no need to worry about actually modelling the concurrency execution flow, blocking I/O or scheduling; just write the code as usual and OS will take care of it. But there is no place for magic in programming world in it has fallen hard once network services started to scale.

Threads are infrastructure just like stack and heap, very, very, very few people actually worry about and manage these resources explicitly, most just leave the run time system to handle it. OK so the usual GC argument can be plopped in here, let's not bother though as we've been through it three times this quarter :-)

> Right now is the glorious moment when engineers are finally starting to appreciate how previous academia research can help them solve practical issues and all this good stuff goes mainstream :)

Actors are mid 1960s, dataflow early 1970s, CSP mid 1970s, it has taken the explicit shared-memory multithreading in applications fiasco a long time to pass. I can think of some applications which are effectively operating systems and so need all the best shared-memory multithreading techniques (I was involved in one 1999–2004), but most applications people should be using actors, dataflow, CSP or data parallelism as their applications model supported by library frameworks/infrastructure.

[…]
> Doubt programming / engineering community will ever accept research that states that choosing architecture can be done on pure theoretical basis :) It simply contradicts too much all daily experience which says that every concurrent application has some unique traits to consider and only profiling can rule them all.

Most solutions to problems or subproblems can be slotted into one of actors, dataflow, pipeline, MVC, data parallelism, event loop for the main picture. If tweaking is needed, profiling and small localized tinkerings can do the trick. I have yet to find many cases in my (computation oriented) world where that is needed. Maybe in an I/O world there are different constraints.

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