Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?

[Atila Neves]

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.