A few notes on choosing between Go and D for a quick project

[Bienlein via Digitalmars-d]

> What about using a JVM with green threads support or Quasar, 
> wouldn't it be more comparable?
>
> --
> Paulo

Long text, contents of common interest in the last section :-)

Thanks for the hints, Paulo. Quasar looks interesting. The 
current number one actor implementation for the JVM is Akka 
(akka.io). It was earlier built on Hawtdispatch 
(https://github.com/fusesource/hawtdispatch), which is similar to 
Quasar but much simpler. Now they have plugged in their own 
scheduler. Those libraries follow the same approach that a small 
number of threads (small to make the overhead of context switches 
small) serve a large number of consumers (e.g., channels, actors, 
or whatever consumer abstraction). This works well as long as all 
tasks are short-runners. It becomes a problem once you have many 
long-runners. Me talking about large fibonacci numbers in my 
previous post was to indicate that it is all about the problem 
with long-runners. In Vert.x they have a separate scheduler for 
long-runners that can serve a certain number of tasks and rejects 
tasks once the max is exceeded. I will check out have they have 
implemented channel select in Quasar. In Go they can do this 
efficiently, because it is done by the built-in scheduler and not 
in the library.

As what D is concerned it has vibe.d, which follows on principle 
the same approach as described above from what I understand about 
it. There is an old discussion about integrating vibe.d in the D 
distribution. This way multi-threading in D comes with batteries 
included as in Go. I still think this is a good idea :-).