www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Swift is getting async, structured concurrency and actors

reply Jacob Carlborg <doob me.com> writes:
As the title says, Swift is getting language support for: async/await 
[1], structured concurrency [2] and actors [3]. The implementation has 
already started, available in master.

Seems like D is more or less the only language without language support 
for async/await now. But perhaps it's possible to implement only in 
library code. Kotlin has language support for coroutines, but 
async/await is implemented in library code. D already has fibers (kind 
of like coroutines) implemented in library code.

[1] 
https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md

[2] 
https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md

[3] 
https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md

-- 
/Jacob Carlborg
Dec 11 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:
 As the title says, Swift is getting language support for: 
 async/await [1], structured concurrency [2] and actors [3]. The 
 implementation has already started, available in master.

 Seems like D is more or less the only language without language 
 support for async/await now. But perhaps it's possible to 
 implement only in library code. Kotlin has language support for 
 coroutines, but async/await is implemented in library code. D 
 already has fibers (kind of like coroutines) implemented in 
 library code.
For D it would make a lot of sense to just add C++ style coroutines. LDC/GDC could just look at the C++ implementation and borrow it.
Dec 11 2020
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 11 December 2020 at 22:12:44 UTC, Ola Fosheim Grøstad 
wrote:
 For D it would make a lot of sense to just add C++ style 
 coroutines. LDC/GDC could just look at the C++ implementation 
 and borrow it.
Are they stackless? Then yes.
Dec 12 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan Koppe 
wrote:
 On Friday, 11 December 2020 at 22:12:44 UTC, Ola Fosheim 
 Grøstad wrote:
 For D it would make a lot of sense to just add C++ style 
 coroutines. LDC/GDC could just look at the C++ implementation 
 and borrow it.
Are they stackless? Then yes.
AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked. It should be possible on MIPS, which doesn't use a stack...
Dec 13 2020
next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad 
wrote:
 On Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan Koppe 
 wrote:
 Are they stackless? Then yes.
AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked.
I just did and from a cursory glance they are. Of course they need to allocate whenever they suspend from anything but the top-level, but most compilers elide that when it can proof the coroutine doesn't escape the calling function. If we do want coroutines, we should just steal it all, it is pretty great work.
Dec 13 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 13 December 2020 at 15:18:53 UTC, Sebastiaan Koppe 
wrote:
 On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim 
 Grostad wrote:
 On Saturday, 12 December 2020 at 10:14:20 UTC, Sebastiaan 
 Koppe wrote:
 Are they stackless? Then yes.
AFAIK conceptually, but maybe the current backend have to save some state from the top frames and reconstruct it on resume? Not sure if current LLVM can support fully stackless, but I haven't checked.
I just did and from a cursory glance they are. Of course they need to allocate whenever they suspend from anything but the top-level, but most compilers elide that when it can proof the coroutine doesn't escape the calling function. If we do want coroutines, we should just steal it all, it is pretty great work.
If you want to bring that into D I advise many of the great talks done by Gor Nishanov, one of the main contributors to the co-routines design, for example “C++ Coroutines: Under the covers" https://www.youtube.com/watch?v=8C8NnE1Dg4A
Dec 13 2020
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 13 December 2020 at 15:49:47 UTC, Paulo Pinto wrote:
 On Sunday, 13 December 2020 at 15:18:53 UTC, Sebastiaan Koppe
 If we do want coroutines, we should just steal it all, it is 
 pretty great work.
If you want to bring that into D I advise many of the great talks done by Gor Nishanov, one of the main contributors to the co-routines design, for example “C++ Coroutines: Under the covers" https://www.youtube.com/watch?v=8C8NnE1Dg4A
Thanks, I will take a look. I recently went down the rabbit hole of some C++ proposals around senders/receivers and cancellation of async tasks. They have some really good ideas. Most of them I am reusing for work. It really all comes together: IO, async, cancellation, nursery, structured concurrency, streams, etc. There are plenty of different approaches in various languages. It would be good to do a thorough review of the landscape and look at how those concepts could be implemented in D, and pick the one that naturally fits the language. D is really lagging in this respect. It has fibers, but they generally use too many resources and aren't portable to platforms like WebAssembly. I really wish I had more time, but I need to finish stuff I started.
Dec 31 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim Grostad 
wrote:
 It should be possible on MIPS, which doesn't use a stack...
All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
Dec 13 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 13 December 2020 at 16:17:32 UTC, IGotD- wrote:
 On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim 
 Grostad wrote:
 It should be possible on MIPS, which doesn't use a stack...
All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
By design, RISCish activation frames. Basically a linked list IIRC. Very common in high level runtimes too. Allows for massive concurrency.
Dec 13 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 14 December 2020 at 01:04:26 UTC, Ola Fosheim Grostad 
wrote:
 On Sunday, 13 December 2020 at 16:17:32 UTC, IGotD- wrote:
 On Sunday, 13 December 2020 at 09:55:29 UTC, Ola Fosheim 
 Grostad wrote:
 It should be possible on MIPS, which doesn't use a stack...
All general purpose CPUs have stacks one way or the other so I'm not sure what you mean that MIPS doesn't use a stack.
By design, RISCish activation frames. Basically a linked list IIRC. Very common in high level runtimes too. Allows for massive concurrency.
Hm, tried to look for it now, but didn't find anything on it for MIPS. Might have been another architecture, but probably not worth it with caches that came in the 90s and then 64-bit. Anyway, the basic idea is that you don't require a contiguous stack, so that you can have many threads without running into address space problems. So, useful for simulations, but also for the ability to detach a computation from one thread and sending it to another one.
Jan 04 2021
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:
 As the title says, Swift is getting language support for: 
 async/await [1], structured concurrency [2] and actors [3]. The 
 implementation has already started, available in master.
I personally think async/await isn't that pretty. I find it very infectious. Before long your whole program has async/await everywhere. If you think about it, async/await, concurrency and coroutines wouldn't exist if it wasn't for IO and our desire to do useful work when a piece of code is waiting on it. Async IO is one way to fix it, but that generally leads to callback hell, and hence to async/await. Vibe.d and photon are two approaches that fix it without callback hell, and thus without async/await. Vibe.d has its warts and photon is mostly DOA, but they do show a promising alternative.
 Seems like D is more or less the only language without language 
 support for async/await now. But perhaps it's possible to 
 implement only in library code. Kotlin has language support for 
 coroutines, but async/await is implemented in library code. D 
 already has fibers (kind of like coroutines) implemented in 
 library code.
It mostly is, but it needs to integrate with the GC as well.
Dec 12 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 11 December 2020 at 20:08:30 UTC, Jacob Carlborg wrote:
 As the title says, Swift is getting language support for: 
 async/await [1], structured concurrency [2] and actors [3]. The 
 implementation has already started, available in master.

 Seems like D is more or less the only language without language 
 support for async/await now. But perhaps it's possible to 
 implement only in library code. Kotlin has language support for 
 coroutines, but async/await is implemented in library code. D 
 already has fibers (kind of like coroutines) implemented in 
 library code.

 [1] 
 https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md

 [2] 
 https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md

 [3] 
 https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md
+1 D. Today we have efforts which have stopped because async/await was missing 😢
Dec 31 2020