Simple web server benchmark - vibe.d is slower than node.js and Go?

[Petar]

On Saturday, 23 September 2017 at 22:07:58 UTC, bitwise wrote:
>
> Of the few different architectures I tried, the fiber based 
> approach was much slower. It's possible that my implementation 
> did too many unnecessary context switches.

Can you give a bit more details? What kind of architectures do 
you mean (hardware, software, ..)?
What was your use case? IO-multiplexing, coarse-grained 
high-level cooperative multi-tasking, or range-like data 
processing state-machines?

>
> I suppose this is off topic, but for games, or any realtime 
> application where things need to run intermittently, but at 
> high frequency, and in high numbers, stackless resumable 
> functions are a big win. A lot of AI I've been writing lately 
> (including some flocking behaviors) have been built on top of 
> C# IEnumerators.

Very interesting, I would like to hear more about your approach. 
I have kind of the opposite experience with C# v7.1. When writing 
synchronous pull-style code I constantly miss the power of D's 
ranges, templates and DbI, when I'm forced to work with C#'s 
IEnumerable<T> extension methods, expression trees and run-time 
reflection.
About push-style asynchronous code, I find async/await unusable 
for anything more than the absolute basic stuff. For 95% of my 
code in this area I use RX.NET (http://reactivex.io/). I'm sure 
they probably use async/await somewhere down in their 
implementation, but I just find that it scales very poorly when 
complexity increases.
My time "lost" by going from Task<T> to IObservable<T> (yes, even 
for single items) is immediately regained by using a few powerful 
operators like Buffer, CombineLatest and Switch.