Async-await on stable Rust!

[Ola Fosheim Grøstad]

On Sunday, 10 November 2019 at 21:49:45 UTC, Russel Winder wrote:
> pretensions to be a general purpose language. The intention has 
> been to integrate well with Python so that Python is the 
> language of the frontend and Chapel is the language of the 
> computational backend – cf. CERN's view of C++ and Python.

Yes, that would make Chapel much more interesting. I think that 
being able to write libraries/engines in a new language and call 
into it from an established high-level language is a good general 
strategy.

Often times language authors see their language as the host 
language and other languages as "subordinate" library languages. 
That is probably a strategic mistake. It is kinda sad that so 
much open source library features have to be reimplemented in 
various languages.


> If we had the money and the team today, I'd hope we would beat 
> Pony, C++, D, Go, Rust, etc. at their own game. Ain't going to 
> happen, but that's life.

You could write up your ideas and create a blog post that 
describes it. I believe there is a reddit for people creating 
their own languages, could inspire someone?


> Intel had the chips in 2008, e.g. The Polaris Chip – cf. 
> SuperComputer 2008 proceedings. But the experiment failed to be 
> picked up for reasons that I have no idea of – possibly the 
> chips were available a decade or more ahead of software 
> developers ability to deal with the concepts.

Ah, interesting, Polaris used network-on-a-chip. According to 
some VLSI websites the Polaris led to Intel's 
many-micro-cores-on-a-chip architecture, which led to Larrabee 
and Xeon Phi. Last version of Phi was released in 2017.

Another type of many-micro-core processors with some local memory 
are the ones geared towards audio/video that use some kind of 
multiplexed grid-like crossbar-databusses for internal 
communication between cores. But they are more in the DSP 
tradition, so not really suitable for actor-style languages I 
think.


> between processes over a kernel thread pool works. NB CSP 
> doesn't stop you creating livelock or deadlock but it does tell 
> you when and why it happens.

Pony claims to be deadlock free: https://www.ponylang.io/discover/

I assume that you could still experience starvation-like 
scenarios or run out of memory as unprocessed events pile up, but 
I don't know exactly how they schedule actors.

> Go was intended to be a replacement for C, so if it feels C-ish 
> the design has achieved success!

Yes… just like Php…