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?
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.
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.
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.
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 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.).
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?