My two cents

[Adam Wilson]

On 10/23/17 22:40, Dmitry Olshansky wrote:
> On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
>> On 10/23/17 17:27, flamencofantasy wrote:
>>> On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
>>>> On 10/23/17 08:21, Kagamin wrote:
>>>>> [...]
>>>>
>>>> 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.
>>>>
>>>> [...]
>>>
>>> There is a lot of misunderstanding about async/await. It has nothing to
>>> do with "conservation of thread resources" or trading "raw performance
>>> for an ability
>>>> to handle a truly massive number of simultaneous tasks". Async/await
>>>> is just 'syntactic sugar' where the compiler re-writes your code into
>>>> a state machine around APM (Asynchronous programming model which was
>>>> introduced in .NET 2.0 sometime around 2002 I believe). That's all
>>>> there is to it, it makes your asynchronous code look and feel
>>>> synchronous.
>>
>>
>> The only parts of Async/Await that have anything to do with APM are
>> the interop stubs. C#'s Async/Await is built around the Task
>> Asynchronous Programming model (e.g. Task and Task<T>) the compiler
>> lowers to those, not APM. A common misunderstanding is that
>> Task/Task<T> is based on APM, it's not, Task uses fundamentally
>> different code underneath. On Linux/macOS it actually uses libuv (at
>> the end of the day all of these programming models are callback based).
>>
>
> I’ll throw in my 2 rubbles.
>
> I actually worked on a VM that has async/await feature built-in (Dart
> language).
> It is a plain syntax sugar for Future/Promise explicit asynchrony where
> async automatically return Future[T] or Observable[T] (the latter is
> async stream).
>
> Async function with awaits is then re-written as a single call-back with
> a basic state machine, each state corresponds to the line where you did
> await.
>
> Example:
>
> async double calculateTax(){
>       double taxRate = await getTaxRates();
>       double income = await getIncome();
>       return taxRate * income;
> }
>
> Becomes roughly this (a bit more mechanical though):
>
> Future!double calculateTax(){
>        int state = 0;
>        Promise!double __ret;
>        double taxRate;
>        double income;
>        void cb() {
>           if(state == 0) {
>             state = 1;
>             getTaxRates().andThen((double ret){
>                  taxRate = ret;
>                  cb();
>             });
>           }
>           else if (state == 1) {
>              state = 2;
>              getIncome().andThen((double ret){
>                  income = ret;
>                  cb();
>             });
>            else if (state == 2){
>                 __ret.resolve(taxRate*income);
>             }
>        }
>        cb();
>   }
>
> It doesn’t matter what mechanics you use to complete promises - be it IO
> scheduler a-la libuv or something else. Async/await is agnostic to that.
>

That was actually my point. Windows and Linux/macOS .NET core do 
different things. It doesn't matter to the dev. You did a better job of 
illuminating it. :)

> Still there is a fair amount of machinery to hide the rewrite from the
> user and in particular print stack trace as if it was normal sequential
> code.
>

And that is the difficulty we face in D. :)

>
>> Yes, C#'s async design does make code look and feel synchronous, and
>> it was intentionally designed that way, but that is not *why* they did
>> Async. That misunderstanding arises from an interview that Anders did
>> in which he was asked why they held Async back for three years after
>> announcing it at PDC08. In that same talk Anders specifically says
>> that the purpose of the Async is to free up threads to continue
>> execution, his example is a Windows Desktop Message Pump and fetching
>> pictures from the internet (long-wait IO), but the principal applies
>> to any thread. They held back async for three years because they
>> needed to refine the language syntax to something that people could
>> learn and apply in a reasonable amount of time. IIRC there is a
>> Channel9 video where Anders explains the evolution of Async Await.
>
> In other words - explicit asynchrony where a thread immediately returns
> with Future[T] and moves on to the next task. It’s just hidden by
> Async/Await.
>

Yup.

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