8 ways to do concurrency and parallelism in Perl 6 - Jonathan Worthington

First, being a bit provocative on your specific suggestions: * ✅ **message passing**. Actor model theory, where mathematics meets physics on the latter's terms, appropriately resolves uncertainty. In addition, it's consistent with good OO decomposition and makes it easier to communicate between components in a heterogenous authorship/ownership distributed computing environment -- like the internet. * ❌ `async`. Devs advocating for PLs whose designers deemed it *necessary* to force devs to color functions tend to advocate for requiring marking asynchronous functions with an `async` keyword or equivalent. But language designers willing to require that all compiler backends/platforms support s…

This author is years behind. > Structured concurrency ... inklings of structured concurrency appeared ... for example, in 2014 ... However, it was this recent wave 2016-2018 of library authors who framed the problem clearly, proposed a coherent solution including cancellation and error propagation semantics The author is only paying attention to recent articles, libraries and hype. These issues have been pondered for decades. In Jonathan's closing remarks during a presentation showing off the clean design (and working code) that is already in place in Perl 6 he noted: > We've had a lot of ... years building these things out of Threads, out of call backs, out of locks. What I've shown…

P6 also avoids coloring of functions (like Go). (It adds support for structured concurrency atop multi prompt (scoped) continuations.)

For me this issue of `async` "coloring" was one of the more interesting aspects of some exchanges I had in this sub late last year in response to a post “Concurrency made easy”: coming soon to a programming language near you*.* Imo the most useful coloring relevant quote from the OP of that post was: >Function coloring is considered a problem or a feature depending on who you talk to. There's certainly no consensus that it should be eliminated. Aiui those two sentences are correct. (Ironically they followed two sentences that showed a fundamental misunderstanding of what is and isn't possible and what is and isn't happening in programming languages. Such misunderstanding may be coloring…

Do you use Perl 5? If not, why not just treat it like a new language? Computers these days pretty much all have multiple cores. Perl 6 makes it easy to use those cores. Languages like Python 2 and 3, which punt on concurrency and parallelism to libraries, and whose interpreters have a GIL, don't. If you would like to be able to easily use those cores, from one-liners to large applications, consider using Perl 6. Most text these days is Unicode. Perl 6 is one of only three languages whose built in string handling understands what a user thinks of as a character. If you would like to be able to easily work with character level processing of international text (including processing substri…

I'll ask questions relative to the two coroutine features that Raku exposes: `await` and `gather`/`take`. `await` returns a list of promises once they've all been kept (or broken). `gather` lazily constructs a list of `take`n values. $promise-outcome = await $one, $or, $more, $promises; $taken = gather ... take $foo, $bar ...; Relative to Raku's `await` and your `wait ...`, what's your rationale for not eliminating the `async` keyword? Relative to Raku's `gather`/`take`, this involves lazy list processing, which introduces complexity, and the `...` in the above summary can include nested lexical scopes (eg nested loops) and/or nested dynamic scopes (ie a stack of function calls)…