Async-await on stable Rust!
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sun Nov 10 14:42:11 UTC 2019
On Sunday, 10 November 2019 at 10:57:19 UTC, Russel Winder wrote:
> Chapel and it's parallelism structures work just fine on a
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
> 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).
More information about the Digitalmars-d