
Asynchronous I/O that doesn’t get in your way, written in D - zyngaro
http://vibed.org
======
danford
Does anyone know if googles V8 could benefit from being re-written (even
partly) in D? I'm mostly a web programmer and only just started learning D, so
I'm not real familiar with how these lower level languages work. It seems like
C++ programmers openly admit that D is better than C++ in many ways, but
because of the lack of documentation (which seems to be a little better as of
late) it just isn't a viable solution for most projects.

I'd like to hear an unbiased opinion of whether D, assuming the proper docs
were available, could replace the C++ code in V8, and if not, what exactly is
holding it back?

~~~
simendsjo
Not answering your question, but there is a research project implementing a
Javascript JIT compiler in D:
[http://pointersgonewild.wordpress.com/higgs/](http://pointersgonewild.wordpress.com/higgs/)

------
kolev
I think D doesn't get the attention it deserves. As far as I can recall,
Facebook was using it for some projects.

~~~
dkhasel
D absolutely deserves more attention. Any ideas on how to attract new folks to
the language?

~~~
WalterBright
Write articles about how you're using D and post them.

------
SamReidHughes
The website says it uses fibers, a.k.a. tasks, a.k.a. coroutines.

So that's what this is.

~~~
camus2
Javascript has fibers and generators.

They definetly help writing async code.

One day one will never have to write callbacks or promises ever again.

ES6 comes with a lot of new features which will make JS a very different
language (classes,guards,annotations...).Things are starting to get very
interesting in js land.

------
norswap
Interesting, but a bit light on how to read/write from TCP (as opposed to
opening a collection). Would love to see some details about what goes on
behind the hood.

~~~
etcimon
The coroutines (fibers/tasks) work in the same way threads do in a kernel.
Vibe.d is a reimplementation with something called "fibers", with task-
messaging, task contexts, context switching.

When using poll or select kernel functions, your thread "yields" and allows
other processes to do some work while your process waits for i/o data. Fibers
work the same way but the waiting happens within your process.

Basically, when all fibers are waiting, there's going to be events in the
kernel (using epoll or iocp) with the associated fiber pointer to wake it up
when something comes up. The fiber (aka task) is called with Fiber.call() when
there's news and automatically restores its stack and context, but maybe it
has more data in the circular buffer or the manual event you were waiting for
was triggered, so the routine can go forward (otherwise, Fiber.yield() is
called again and waits for an event from the kernel).

This allows the code to stay linear somewhat. Low-level buffers are all meant
to yield when data is not available. Every time a new connection happens, a
new fiber is created, same goes when you call runTask.

------
EvenThisAcronym
Is there a reference anywhere for the utility stuff that comes with Vibe.d, or
are we expected to read the source on Github?

~~~
sol1684
There is an API reference: [http://vibed.org/api/](http://vibed.org/api/) And
a higher level overview: [http://vibed.org/docs](http://vibed.org/docs)

