Well, the first round was certainly interesting!

Lots of great samples of potential solutions for feature parity with the Clojure one were posted here:

https://old.reddit.com/r/programming/comments/cwgvxl/clojure_vs_blub_lang_parallelism/ and here: https://old.reddit.com/r/Clojure/comments/cwgvvi/clojure_vs_blub_lang_parallelism/

Unfortunately, the majority of them knowing (or with caveat included / knowingly) provided a concurrent solution, not a parallel solution.

What's the difference? Well, a concurrency problem is equivalent to:

You are working on a product feature, and hit a blocker. Soandso must complete an update to their API before you can finish one portion of your feature. Instead of sitting and twiddling your thumbs (non-concurrent) you begin to work on a different part of your feature, while you wait for theirs to finish. That's concurrency.

Parallelism would be more akin to killing two birds with one stone - you have 2 tasks you need to take care of - bringing a peer up to speed on some programming techniques, as well as delivering your feature. You pull your peer into a peer-programming session and manage to complete 2 tasks in the time it would have taken to complete the single task (now, substitute tasks for computations - that's parallelism).

While the simulation in the round 1 post (http://ahungry.com/blog/2019-08-28-Round-1-Clojure-vs-Blub-Lang-Parallelism.html) did lend itself closer to a waiting/idle problem (waiting on a remote HTTP request, aka a concurrency issue, not a computational bottleneck, and truly a concurrency problem as most implementors used an idling delay, aka sleep), the Clojure solution covered both aspects equally, while most the others only solve for concurrency and do nothing to assist with parallelism. Note - no extra thought went into creating the initial Clojure solution to ensure it handled concurrency and parallelism equally well - its a language freebie.