On Wednesday, 7 October 2015 at 10:48:02 UTC, Russel Winder wrote:
On Wed, 2015-10-07 at 07:15 +0000, extrawurst via Digitalmars-d
wrote:
[…]
I have never used Go, but isn't what you describe exactly what
vibe.d is doing using Fibers ?
As I understand it, vibe.d is a single threaded event-loop with
fibres. In this sense it is equivalent in architecture to Node
except that vibe.d allows for blocking fibres where Node
required non-blocking approaches. Thus I would choose vibe.d
over Node any day, except…
vibe.d supports multiple threads and will schedule tasks on
separate threads if asked to. Each of those threads will in turn
have several fibres. The main difference from Go's runtime for me
are twofold:
1. vibe.d is a library, goroutines are part of the library
2. vibe.d (like D itself) uses the actor model, go is (sort of,
according to some) CSP
My "Go vs D vs C vs Erlang" MQTT shootout was based on a
colleague claiming that Go would win because concurrency is its
thing. I called his bluff since despite Go having a (AFAIK) very
good scheduler, I didn't see how vibe.d wouldn't give me the same
performance. I was right.
Atila
