Asynchronous I/O that doesn’t get in your way, written in D

> what exactly is holding it back?

the size and the complexity of V8 codebase.

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

As far as I've ever seen, Google have no particular interest in D. Facebook have expressed quite a bit of support, but Google just have a way of doing there own thing (Dart, Go, forking WebKit etc). Another problem with Google is that they're fickle, fragmented, and known for crappy support.

> It seems like C++ programmers openly admit that D is better than C++ in many ways.

Anecdotally, I've not seen this. The vibe I've picked up on over the years seems to be that D is and was always seen as a cleaner, but slightly less powerful, C++ with a lot of potential... but now C++ standardisation has accelerated, there's just much more comfort amongst C++ devs that the language looking forward is good. C++ is almost as old as C and evolving faster than ever. If anything though, Rust seems to be the serious topic of choice atm.

As a language, C++ is used in many different niches, because it allows such low-level control of the machine. However it has many problems around the edges, because it was essentially hacked ontop of C. D is designed to get around these problems, and provide a better OOP langauge. So it lacks some low-level control that C++ has, which you require for for a JIT, which is used in V8. So you'd want to stick with C or C++ for something like V8.

There are also two other recent languages designed to replace niches of C++: Go in latency-sensitive, real time systems, and Rust in systems programming. Rust is quite interesting though, since it introduces many data-safety concepts from function programming into an imperative language.

They are, and even talked about it at dconf 2014. The video will be uploaded within some days. http://dconf.org/2014/talks/simpkins.html

Here's one of the projects written for Facebook by Walter Bright: https://github.com/facebook/warp

Sociomantic is a $100m annual revenue company:

https://www.sociomantic.com/dunnhumby-acquires-sociomantic/

that uses 100% D to drive its trading software:

https://www.sociomantic.com/technology/

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

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.

The documentation for raw TCP might be a bit sparse: http://vibed.org/docs#raw-tcp

There was a talk on dconf 2013 about vibe: http://dconf.org/2013/talks/panteleev.html Notice the slides and video links. It focuses on web development, but you'll get some insight into vibe.d that's valid for TCP too.

There is a coarse description on the "features" page of how blocking operations in general are handled. The same principle applies to all kinds of blocking operations (waiting for a mutex lock, sleeping, waiting for data on a pipe etc.).

http://vibed.org/features#fibers

It still doesn't go into full detail, though, and a dedicated article would probably be worthwhile to write.

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.

There is an API reference: http://vibed.org/api/ And a higher level overview: http://vibed.org/docs