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

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.

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.

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.

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...

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.

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

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.

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.

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

It would also make is easier for our team to migrate from C# to D. Today we have efforts which have stopped because async/await was missing 😢