www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - async / await

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
1. What are the hurdles to overcome to enable the async / await 
keywords in D?


shorten a lot of code.


(https://docs.microsoft.com/en-us/dotnet/api/system.threading.task
.task?view=net-5.0) in D?



I began making a list of corresponding language constructs 

work. But then there's that async stuff...
Oct 07 2021
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 7 October 2021 at 12:47:16 UTC, Imperatorn wrote:

 1. What are the hurdles to overcome to enable the async / await 
 keywords in D?


What it would benefit to have them as keywords? Don't the  
[functions in 
Vibe.d](https://vibed.org/api/vibe.core.concurrency/) work just 
as well?
Oct 07 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 7 October 2021 at 20:31:42 UTC, Dukc wrote:

 On Thursday, 7 October 2021 at 12:47:16 UTC, Imperatorn wrote:

 1. What are the hurdles to overcome to enable the async / 
 await keywords in D?


 What it would benefit to have them as keywords? Don't the  
 [functions in 
 Vibe.d](https://vibed.org/api/vibe.core.concurrency/) work just 
 as well?


Mainly when porting from other languages, but it's also faster to 
write asynchronous logic with it in general.
Oct 07 2021
parent reply russhy <russhy gmail.com> writes:

it promotes creating bad APIs (GetThisAsync | 
GetThisAsync.ButSyncThisTimeToGetResult)

https://kristoff.it/blog/zig-colorblind-async-await/

Zig's approach is cleaner imo
Oct 07 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 7 October 2021 at 22:35:23 UTC, russhy wrote:


 idea, it promotes creating bad APIs (GetThisAsync | 
 GetThisAsync.ButSyncThisTimeToGetResult)

 https://kristoff.it/blog/zig-colorblind-async-await/

 Zig's approach is cleaner imo


I think you misunderstood me. What I meant was just the 
async/await keywords
Oct 07 2021
parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 7 October 2021 at 23:20:15 UTC, Imperatorn wrote:

 On Thursday, 7 October 2021 at 22:35:23 UTC, russhy wrote:


 idea, it promotes creating bad APIs (GetThisAsync | 
 GetThisAsync.ButSyncThisTimeToGetResult)

 https://kristoff.it/blog/zig-colorblind-async-await/

 Zig's approach is cleaner imo


 I think you misunderstood me. What I meant was just the 
 async/await keywords


No, he understood you and is talking about the method 


But tbh. the solution is to provide both an asynchronous and a 
synchronous version of the method.

Ex.

DownloadFile() would be synchronous, whereas DownloadFileAsync() 
would then be async.

That avoids the whole problem of calling an async method 
synchronous, because in general you shouldn't ever do that anyway!
Oct 07 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 8 October 2021 at 06:38:17 UTC, bauss wrote:

 On Thursday, 7 October 2021 at 23:20:15 UTC, Imperatorn wrote:

 On Thursday, 7 October 2021 at 22:35:23 UTC, russhy wrote:


 idea, it promotes creating bad APIs (GetThisAsync | 
 GetThisAsync.ButSyncThisTimeToGetResult)

 https://kristoff.it/blog/zig-colorblind-async-await/

 Zig's approach is cleaner imo


 I think you misunderstood me. What I meant was just the 
 async/await keywords


 No, he understood you and is talking about the method 


 But tbh. the solution is to provide both an asynchronous and a 
 synchronous version of the method.

 Ex.

 DownloadFile() would be synchronous, whereas 
 DownloadFileAsync() would then be async.

 That avoids the whole problem of calling an async method 
 synchronous, because in general you shouldn't ever do that 
 anyway!



an example rather than for example Zig.

The keywords are separate from the implementation. The same way 
that if we didn't have foreach as a keyword and decided to 
introduce it.

I was mainly talking about the purely syntactic aspect of the 
source code.

It would (also) make the porting of Zig/[insert language here] to 
D easier.
Oct 08 2021
prev sibling parent reply ikod <igor.khasilev gmail.com> writes:
On Friday, 8 October 2021 at 06:38:17 UTC, bauss wrote:

 On Thursday, 7 October 2021 at 23:20:15 UTC, Imperatorn wrote:

 On Thursday, 7 October 2021 at 22:35:23 UTC, russhy wrote:


 idea, it promotes creating bad APIs (GetThisAsync | 
 GetThisAsync.ButSyncThisTimeToGetResult)







 Ex.

 DownloadFile() would be synchronous, whereas 
 DownloadFileAsync() would then be async.


This is not always useful to have different names for interfaces, 
especially when application developer decide for some 
performance/scalability/etc reason to port sync code to async 
environment.

DownloadFile can be implemented such that it detects if it work 
in sync or async environment like (in pseudocode):


void DownloadFile() {
     if (activeEventLoopDetected) {
         wait asyncCode
     } else {
         call syncCode
     }
}


 That avoids the whole problem of calling an async method 
 synchronous, because in general you shouldn't ever do that 
 anyway!
Oct 08 2021
parent bauss <jj_1337 live.dk> writes:
On Friday, 8 October 2021 at 10:19:40 UTC, ikod wrote:

 On Friday, 8 October 2021 at 06:38:17 UTC, bauss wrote:

 On Thursday, 7 October 2021 at 23:20:15 UTC, Imperatorn wrote:

 On Thursday, 7 October 2021 at 22:35:23 UTC, russhy wrote:


 idea, it promotes creating bad APIs (GetThisAsync | 
 GetThisAsync.ButSyncThisTimeToGetResult)







 Ex.

 DownloadFile() would be synchronous, whereas 
 DownloadFileAsync() would then be async.


 This is not always useful to have different names for 
 interfaces, especially when application developer decide for 
 some performance/scalability/etc reason to port sync code to 
 async environment.

 DownloadFile can be implemented such that it detects if it work 
 in sync or async environment like (in pseudocode):


 void DownloadFile() {
     if (activeEventLoopDetected) {
         wait asyncCode
     } else {
         call syncCode
     }
 }


 That avoids the whole problem of calling an async method 
 synchronous, because in general you shouldn't ever do that 
 anyway!




I'm not saying it's the best way to do it. I'm just stating
Oct 08 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 7 October 2021 at 12:47:16 UTC, Imperatorn wrote:

 1. What are the hurdles to overcome to enable the async / await 
 keywords in D?


 also shorten a lot of code.


 (https://docs.microsoft.com/en-us/dotnet/api/system.threading.task
.task?view=net-5.0) in D?



 I began making a list of corresponding language constructs 

 work. But then there's that async stuff...




If not integrated in the language via keywords, how could one 
accomplish it using the "keywords" anyway? Could udas be used? 
 async  await?

Could "compile time magic" lower to something?

I find it hard to believe that it would be *impossible* since D 
is one of the most plastic statically typed languages I know.
Oct 08 2021
parent reply jfondren <julian.fondren gmail.com> writes:
On Friday, 8 October 2021 at 11:14:54 UTC, Imperatorn wrote:

 If not integrated in the language via keywords, how could one 
 accomplish it using the "keywords" anyway? Could udas be used? 
  async  await?

 Could "compile time magic" lower to something?


D doesn't have AST macros, which is what the usual transformation 
requires:

https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncmacro.nim#L253

That's just syntax, though. It's putting the cart a hundred miles 
before the horse to want syntax from dmd when the functionality 
it would lower to is also not there. You could easily build 
something over vibe's fiber scheduler and std.concurrency, but 

code with very different performance characteristics. It'd be 
like dmd adding a goroutine syntax that lowers to the phobos 
FiberShcheduler, where some benchmarks in Learn have it 8x slower 
than go: it would be better to rethink that code for D.

If you want the familiar syntax, the better immediate goal is 
some existing D syntax that works with a 
tokio/asyncdispatch/etc.-competitive async scheduler.


 I find it hard to believe that it would be *impossible* since D 
 is one of the most plastic statically typed languages I know.
Oct 08 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 8 October 2021 at 11:34:29 UTC, jfondren wrote:

 On Friday, 8 October 2021 at 11:14:54 UTC, Imperatorn wrote:

 [...]


 D doesn't have AST macros, which is what the usual 
 transformation requires:

 [...]


Sad
Oct 08 2021
parent reply jfondren <julian.fondren gmail.com> writes:
On Friday, 8 October 2021 at 12:21:50 UTC, Imperatorn wrote:

 On Friday, 8 October 2021 at 11:34:29 UTC, jfondren wrote:

 On Friday, 8 October 2021 at 11:14:54 UTC, Imperatorn wrote:

 [...]


 D doesn't have AST macros, which is what the usual 
 transformation requires:

 [...]


 Sad


D doesn't have any syntax to support an actor framework either, 
but it still has a very natural one in std.concurrency. It 
doesn't have any syntax to support pattern matching over ML 
datatypes but it has std.sumtype. If you focus on functionality 
first and syntax later, you might find you want that much for 
syntax in the end.
Oct 08 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 8 October 2021 at 12:30:18 UTC, jfondren wrote:

 On Friday, 8 October 2021 at 12:21:50 UTC, Imperatorn wrote:

 On Friday, 8 October 2021 at 11:34:29 UTC, jfondren wrote:

 On Friday, 8 October 2021 at 11:14:54 UTC, Imperatorn wrote:

 [...]


 D doesn't have AST macros, which is what the usual 
 transformation requires:

 [...]


 Sad


 D doesn't have any syntax to support an actor framework either, 
 but it still has a very natural one in std.concurrency. It 
 doesn't have any syntax to support pattern matching over ML 
 datatypes but it has std.sumtype. If you focus on functionality 
 first and syntax later, you might find you want that much for 
 syntax in the end.


Hmm, I just assumed that it did because it's so similar to Erlang
Oct 08 2021