How I Came to Write D -- by Walter Bright

[Sönke Ludwig]

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?