Async-await on stable Rust!
russel at winder.org.uk
Sun Nov 10 21:49:45 UTC 2019
On Sun, 2019-11-10 at 14:42 +0000, Ola Fosheim Grøstad via Digitalmars-d
> 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
> 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
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...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the Digitalmars-d