Asynchronous I/O that doesn’t get in your way, written in D(vibed.org)
vibed.org
Asynchronous I/O that doesn’t get in your way, written in D
http://vibed.org
5 comments
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.
> 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.
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.
> what exactly is holding it back?
the size and the complexity of V8 codebase.
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/
I think D doesn't get the attention it deserves. As far as I can recall, Facebook was using it for some projects.
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
Here's one of the projects written for Facebook by Walter Bright: https://github.com/facebook/warp
Nice! Didn't pay attention earlier that it's in D!
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/
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
that uses 100% D to drive its trading software:
https://www.sociomantic.com/technology/
Thanks! I really hope D gains more popularity as it's a beautifully-crafted language!
D absolutely deserves more attention. Any ideas on how to attract new folks to the language?
Write articles about how you're using D and post them.
Have a compiler that can actually be compiled.
The website says it uses fibers, a.k.a. tasks, a.k.a. coroutines.
So that's what this is.
So that's what this is.
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.
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.
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.
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.
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 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.
http://vibed.org/features#fibers
It still doesn't go into full detail, though, and a dedicated article would probably be worthwhile to write.
Is there a reference anywhere for the utility stuff that comes with Vibe.d, or are we expected to read the source on Github?
There is an API reference: http://vibed.org/api/
And a higher level overview: http://vibed.org/docs
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?