Async-await on stable Rust!

[Ola Fosheim Grøstad]

On Sunday, 10 November 2019 at 10:57:19 UTC, Russel Winder wrote:
> Chapel and it's parallelism structures work just fine on a 
> laptop.

Ok, maybe I've read the Chapel spec through a SGI-lens that has 
made me a bit biased there.  I will have to give Chapel a spin to 
figure it out, but quite frankly, right now the future of C++ 
seems more interesting than Chapel from a pragmatic 
application-programming concurrency viewpoint, with the upcoming 
concurrency-related extensions, stackless coroutines etc. I 
cannot really see myself using Chapel to build a desktop 
application. Maybe unjustified bias on my part, though.

>> I've got a feeling that some model reminiscent of actor based 
>> languages will take over at some point. E.g. something closer 
>> to Go and Pony, but with local memory baked in as a design 
>> premise.
>
> We were saying that in 1988, my research team and I even 
> created a programming language, Solve – admittedly active 
> objects rather than actors but in some ways the two are 
> indistinguishable to most programmers. We even did a couple of 
> versions of the model based on C++ in the early 1990s: UC++ and 
> KC++. I am still waiting for people to catch up. I am not 
> holding my breath, obviously.

Cool, I think really the hardware is the main issue, and 
"installed base" issues with existing applications requiring the 
current hardware model. So, lately speed has primarily come from 
special processors, GPUs, first as SIMD-style VLIW, now as 
many-core RISC to be more flexible.

So it might take time before we see "clusters" of simple CPUs 
with local memory. Maybe it will come through embedded. Maybe 
with automation/robotics, where you don't want the whole machine 
to fail just because a small part of it failed. But culture is a 
strong force... so the "not holding my breath" makes sense... :-/

> Chapel and Pony are the interesting ones here. Chapel I believe 
> can get traction since it is about using declarative 
> abstractions to harness parallelism on a PGAS model. Pony I 
> fear may be a bit too niche to get traction but it proves 
> (existence proof) an important point about actors that 
> previously only Erlang was pushing as an idea.

Outside research languages, I agree. For supported languages 
Chapel and Pony are very interesting and worth keeping an eye on, 
even if they have very low adoption. You can also take their core 
ideas with you when programming in other languages.

> Go is not uninteresting, exactly the opposite since it is based 
> on processes and channels, and effectively implements CSP. 
> However far too many people using Go are failing to harness 
> goroutines properly since they have failed to learn the lesson 
> that shared memory multi-threading is not the right model for 
> harnessing parallelism.

That is probably true. I've only used Go routines in the most 
limited trivial way in my own programs (basically like a future). 
There are probably other patterns that I could consider, but 
don't really think of.

Although, I don't really feel the abstraction mechanisms in Go 
encourage you to write things that could become complex... I 
haven't written enough Go code to know this for sure, but I tend 
to get the feeling that "I better keep this really simple and 
transparent" when writing Go code. It is a bit too C-ish in some 
ways (despite being fairly high level).