On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
Are there any tutorials or blog posts out there demonstrating
how to use this? I think posts along the lines of "This is a
CSP/message passing program in Go/Erlang. This is the same
program translated into D; look how concise and faster it is!"
could attract a lot of interest.
There are no detailed blog posts and I believe only few
developers are really well proficient with this vibe.d
functionality. Some relevant docs:
http://vibed.org/api/vibe.core.core/
http://vibed.org/api/vibe.core.concurrency/
http://vibed.org/api/vibe.core.task/
Reading the code in the pull request [1], for instance, makes
me wonder how to tell if `spawn()` is spawning a thread or a
fibre. Can a tid refer to a fibre? If so, why's it called a
thread ID, and how do I tell if a particular tid refers to a
thread or fibre? It would be great to have these kinds of
questions answered in an easily available reference (for
instance, the documentation for std.concurrency, which
currently doesn't even mention fibres or vibe.d).
1. https://github.com/D-Programming-Language/phobos/pull/1910
Problem is that this is most simple PR to simply add
message-passing support for fibers. Adding some advanced
schedulers with worker thread pool can be expected to be done
on top but.. This small PR has been rotting there for ages with
pretty much zero attention but from few interested persons.
I can't blame Sonke or anyone else for not wanting to waste his
time on pushing more stuff upstream considering how miserable
contribution experience is right now. We can't really expect
anything else to improve why it stays that bad - Andrei has
mentioned that during his keynote but nothing has been ever
done to improve the situation.
Scala has also a history of three implementations of actor
system, until akka is merged into official support (with Akka's
arthur Jonas Bonér becoming CTO of Typesafe).
In vibe.d's case I think first people don't really know that
there is a good fiber based actor system already in vibe.d, for
that I think it would benefit by separating out to be a
standalone library, then add more functionalities like location
transparency of actors in akka. Otherwise people would only
recognize vibe.d as a networking lib, with no intent to look for
actors there.
