Sure, I'd love to see CSP in D as well. I think that Go's
advantage is simplicity. If you want to try the same code on more
system threads, all you need to do is increase GOMAXPROCS. With
vibe.d it requires some work. It's not a lot of work but it isn't
as easy as with Go.
OTOH, D + vibe.d give you more control. If I want to have a
dedicated thread to do some tasks and tweak the system, I can. I
tried a bunch of different approaches to use threads to try and
make it go faster that (AFAIK) I wouldn't have been able to in
Go. None of them ended up speeding anything up, but I learned a
lot and it was fun trying.
Atila
On Friday, 7 March 2014 at 18:01:53 UTC, Russel Winder wrote:
On Fri, 2014-03-07 at 12:23 +0000, Atila Neves wrote:
[…]
I suspect you might have missed the point of my original blog
post. Yes, it shows D beating Erlang and Go, and that's
something I obviously like. But that wasn't the point I was
trying to make. My point was that just by writing it in Go
doesn't mean magical performance benefits because of its CSP,
and that vibe.d's fibers would do just fine in a direct
competition. The data seem to support that.
That doesn't mean a CSP and dataflow implementations for D (à la
DataRush, GPars, Go, PythonCSP, PyCSP) shouldn't attempted.
Sadly I
think I do not have the time to drive such an endeavour, but I
wish I
could contribute to it if someone else could drive.
