D Web Services Application Potential?

[Etienne Cimon via Digitalmars-d]

On Sunday, 26 July 2015 at 03:04:21 UTC, Brandon Ragland wrote:
> On Sunday, 26 July 2015 at 02:53:12 UTC, Etienne Cimon wrote:
>> On 2015-07-25 22:35, Brandon Ragland wrote:
>>> On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote:
>>>> [...]
>>>
>>> In relation to DDB: Have you seen: 
>>> https://github.com/buggins/ddbc
>>>
>>> It's most similar to the JDBC driver in Java. Currently 
>>> supports MySQL,
>>> PostgreSQL and SQLite. That might be a good starting point to 
>>> expand the
>>> SQL driver support for a web framework.
>>>
>>> I dug around some of your repos, too early to comment but 
>>> I'll sift
>>> through more of it as time allows, see if I can't offer 
>>> anything towards
>>> your current goals in the near future.
>>>
>>> I fully agree that D would be a great fit for web development.
>>>
>>> Thanks for the reply.
>>>
>>>
>>
>> Yes, the goal is to avoid libpq. A typical Vibe.d TCP 
>> Connection is based on what you know as Green Threads, it's 
>> called Tasks/Fibers in D. It means you have to avoid any 
>> library that uses thread-blocking I/O because you're using 1 
>> thread to handle all requests.
>
> That would make sense then.
>
> Was unaware vibe.d was using green threading. The JVM dropped 
> green threads circa 1.2, a long time ago.
>
> I suppose the complexity of asynchronous I/O was never 
> implemented to avoid these blocking issues with fibers/tasks?

There's a way to avoid the blocking by spawning more threads 
(through worker tasks), but it's so much more efficient to use 
native protocol implementations. After all, this is how D and 
vibe.d can get the most req/s compared to the other native 
frameworks. Somebody took the time to write a very elaborate 
standoff and it shows a pretty accurate picture of it: 
https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/