D and Async I/O

[Russel Winder]

On Mon, 2020-05-18 at 11:56 +0000, Sebastiaan Koppe via Digitalmars-d-learn
wrote:
> On Thursday, 14 May 2020 at 09:36:33 UTC, Russel Winder wrote:
> > Whilst C frameworks use callbacks and trampolines, high level 
> > languages seem to be basing things on futures – or things that 
> > are effectively isomorphic to futures.
> 
> What I find most lacking is proper cancellation. Also, futures 
> are eager.

Whilst GIO has an explicit cancellation stack parameter for all its async
operations, I am not sure it is really necessary for the sort of applications
I would write – I use null in all cases. Futures are neither eager nor lazy in
and of themselves. I am not sure why this is an issue, futures are futures and
promises are promises; they are what they are.

> > Concurrency and parallelism will never be solved problems I 
> > suspect, but I think there is a fairly good consensus now on 
> > what is state of the art.
> 
> I haven't found a language that ticks all the boxes. Kotlin comes 
> close.

We have different needs. I am finding Python's asyncio/async/await and Rust's
async/.await with futures perfectly reasonable for creating asynchronous (aka
reactive in the hipster jargon) code. The Gio networking stuff is all very C.
The Python PyGobject API to it doesn't seem to work, and the Rust API is still
a work in progress (the client side works fine, the server-side needs work,
and it all needs adding to gtk-rs.

> > > I think there are a lot of lessons to be learned from all the 
> > > efforts in the programming community.
> > > 
> > > We should:
> > > 
> > > - get stackless coroutines
> > > - get structured concurrency
> > > - steal as many idea from the C++'s executors proposal
> > > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r13.html)
> > 
> > I am not convinced C++ has the best "state of the art" in this 
> > respect – after all it is just copying what JVM languages have 
> > had for ages, and Rust updated for modern native code languages.
> 
> I am not sure you have read the proposal. Initially I brushed it 
> off, but upon closer inspection I realised there are some gems in 
> there.

You are right. I will read it fully rather than just the abstract. Perhaps the
C++ folk have learned lessons from the Kotlin, Python, and Rust stuff to have
something better. I'm still not going to use C++, but it doesn't hurt to learn
good lessons.

The crucial need from my perspective is having channels, aka queues that
create events on the event loop. gtk-rs has shown how to integrate futures and
channels really quite well.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20200519/a026c4c7/attachment.sig>