Async-await on stable Rust!

[Russel Winder]

On Sun, 2019-11-10 at 14:42 +0000, Ola Fosheim Grøstad via Digitalmars-d
wrote:
[…]
> 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.

Chapel is very definitely a language for computationally intensive code, a
replacement for Fortran (and C++). It has no 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. The first attempts
at integration of Python and Chapel didn't work as well as hoped and were
dropped. Now there are new ways of inter-working that shows some serious
promise. One of these is Arkouda https://github.com/mhmerrill/arkouda  I
haven't tried this yet, but I will have to if I decide to go to PyConUK 2020.

[…]
> 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.

In hindsight, what we were trying to do with programming languages in late
1980s and early 1990 was at least a decade too early – the processors were not
up to what we wanted to do. A decade or a decade and half later and we would
have had no problem. The issue was not processor cycles, it was functionality
to support multi-threading at the kernel level, and fibres at the process
level. 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.

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

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.

[…]
> 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).

Go implementation of CSP is not infallible, it is still possible to create
livelock and deadlock – but you do have to try very hard, or be completely
unaware of how message passing 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.

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

-- 
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/attachments/20191110/9dd53912/attachment.sig>