My two cents

[Adam Wilson]

On 10/23/17 08:21, Kagamin wrote:
> On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:
>> Others are less obvious, for example, async/await is syntax sugar for
>> a collection of Task-based idioms in C#.
>
> Now I think it's doesn't fit D. async/await wasn't made for performance,
> but for conservation of thread resources, async calls are rather
> expensive, which doesn't fit in D if we prefer raw performance. Also I
> found another shortcoming: it doesn't interoperate well with cache:
> cache flip flops between synchronous and asynchronous operation: when
> you hit cache it's synchronous, when you miss it it performs IO.

Actually I think it fits perfectly with D, not for reason of 
performance, but for reason of flexibility. D is a polyglot language, 
with by far the most number of methodologies supported in a single 
language that I've ever encountered.

Additionally, MSFT/C# fully recognizes that the benefits of Async/Await 
have never been and never were intended to be for performance. 
Async/Await trades raw performance for an ability to handle a truly 
massive number of simultaneous tasks. And it is easy to implement both 
blocking and non-blocking calls side-by-side (MSFT appends 'Async' to 
the blocking call name).

Here is the thing. Many projects (particularly web-scale) are not all 
that sensitive to latency. Adding 10ms to the total call duration isn't 
going to effect the user experience much when you've got 500ms of IO 
calls to make. But blocking calls will lock up a thread for those 500ms. 
That can disastrous when you have thousands of calls coming in every 
second to each machine.

On the flip side, if you're a financial service corp with millions to 
throw at hardware and an extreme latency sensitivity, you'll go for the 
blocking calls, because they absolutely do cost less in overall 
milliseconds. And you'll make up for the thread blockages by throwing an 
obscene amount of hardware at the problem. Because hey, you're a 
multi-billion dollar corp, you'll make back the few million you spent on 
over-provisioning hardware in a day or two.

The point is that not everyone wants, or needs, maximum raw performance 
per individual task. In the spirit of flexibility, D needs to provide 
the other choice, because it's not our job to tell our users how to run 
their business.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;