On Tue, 2020-05-12 at 09:57 +0000, Sebastiaan Koppe via Digitalmars-d-learn
wrote:
[…]
> 
> Yeah it is a shame, but you see it in almost every language. Probably means concurrency and io isn't a fully solved problem yet.

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. 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. D as a language is lagging, and this is sad.

[…]
> 
> 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. But yes, if D doesn't get something in the async/await style then its future (!) is non-existent. :-(

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

On Tue, 2020-05-12 at 20:05 +0200, Jacob Carlborg via Digitalmars-d-learn wrote:
> On 2020-05-12 11:23, Russel Winder wrote:
> 
> > As far as I can tell D has no futures…
> 
> Future and async in vibe.d [1]. Future in Mecca [2].
> 
> [1] https://vibed.org/api/vibe.core.concurrency/async
> [2]
> https://github.com/weka-io/mecca/blob/0593a35dd1a9978855d7db349fc1172f04cf8013/src/mecca/reactor/sync/future.d#L23

D needs something at the language level on which Vibe.d and Mecca build. This is a lesson from Rust, Kotlin, Python, etc. worth taking up.

Unfortunately, I can't see D changing because it seems not enough people with interest in developing the language have the resource/interest in this. :-(

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

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.

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

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

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