Am 16.04.2014 12:18, schrieb Bienlein:
I use vibe.d for a small server side application. It's quite fast,
although we haven't tested it on a larger scale yet. On the downside,
vibe.d's API is not quite intuitive, so it takes a while to get used
to it. But that might be down to the fact that it's not easy to write
an intuitive API for the web with all the different bits and pieces
that have different logics to them.
If I see things right vibe.d is distributed. Channels and goroutines in
Go aren't! It's just concurrency being very simple through the use of
goroutines and channels that makes Go appealing to things that by nature
use to be concurrent.
What exactly do you mean exactly by? From what I gather about
goroutines, the concept is very similar actually.
When talking about the HTTP server component, incoming requests are
distributed among different "tasks", where a "task" is the equivalent of
a goroutine (basically a fiber in Druntime terms). Optionally, these
tasks can also live in different threads to improve performance (at the
expense of making inter task communication more expensive/complex).
There are currently no channels exposed like they are in Go, but there
is the concurrency module for inter-task message passing.
In Java there is vert.x, which is pretty much the same thing as vibe.d.
But the success in using Go for server-side applications comes from
plain local concurrency being simple the way it is >built into the
language<.
Vert.x actually uses a very different approach to dealing with
concurrency. It basically uses asynchronous I/O only for handling
incoming connections and then continues to use a thread pool to deal
with concurrency in a classical thread based approach. Vibe.d always
uses asynchronous I/O dispatched to any number of quasi-parallel tasks
that appear to have normal control flow.
On the other hand, I don't think there is a significant difference
between Go and vibe.d when it comes to language vs. library. The only
exception that I can think of right now may be that you have to use
TaskLocal!T for creating task local variables as opposed to having a
built-in syntax. But AFAIR global variables in Go are always "shared",
so that doesn't really count either.
I don't see any system for Go that comes close to vibe.d or vert.x. What
makes the difference is that concurrency as such is in the language and
through the use of CSP has become very easy to use. Making concurrency
in D very easy >in the D language< is what would IMHO make the difference.
Can you give a concrete example of what features would be easier if it
was built-in?
