Asynchrony is not concurrency

We plan to have in Zig a testing `Io` implementation that will potentially use fuzzing to stress test your code under a concurrent execution model.

That said, I think a key insight is that we expect most of the library code out there to not do any calls to `io.async` or `io.asyncConcurrent`. Most database libraries for example don't need any of this and will still contain simple synchronous code. But then that code will be able to be used by application developers to express asynchrony at a higher level:

   io.async(writeToDb)
   io.async(doOtherThing)

Which makes things way less error prone and simpler to understand than having async/await sprinkled all over the place.

I do not see these definitions as quite right:

>Asynchrony: the possibility for tasks to run out of order and still be correct.

I like this. Great addition and yes it was missing.

>Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching.

I would say here, be it multiprocessing or task switching.

>Parallelism: the ability of a system to execute more than one task simultaneously at the physical level.

This is technically multiprocessing as expressed above.

So, what is the difference between parallelism and concurrency?

Parallel tasks are like shaders. It is the same task, running many instances at the same time at the physical layer.

GPU devices are capable of parallel computing, for example.

Concurrent tasks are different tasks running at the same time at the physical layer. Often, the data is different too. Say a sprite engine running at the same time as a video display driver on the physical layer.

The shaders can all be running the same code but are processing different data elements, say each pixel having a position and is part of a larger rendering.

A GPU is a massively parallel multiprocessor.

A Threadripper is a massive Concurrent multiprocessor. It can also perform as a modest parallel multiprocessor.

The difference lies in what the various compute units can do and what they are actually doing.

Put another way, a 10ghz single core CPU is not a multiprocessor. It performs sequential computing and it can task switch to handle the same task load as a lower clock rate multiprocessor would handle.

A 10ghz multi core CPU is a concurrent multiprocessor, but is not a GPU. It could run shaders on par with a lower clock GPU. BUT a lower clock GPU cannot run a variety of tasks in the same way.

More powerful than a “fuzzing” test io would be a deterministic test io. I.e., one you can tick forward the various concurrent branches deterministically to prove that various races are safely handled. This makes it possible to capture all those “what if thread A executes this line first then B is executed” etc. Something that is missing in most concurrent frameworks.

For the first one, it really feels like only a matter of how you break lines. Sure there is also the matter of anonymous function syntax, but

The latter is more fair, here is a possible solution:

  const gen = (function* () {
    for (let i = 0; i  !next.done && next.value.then(() => run(gen.next()));
  run(gen.next());

Or something similar using reduce. But in both cases, it illustrates the point, I guess.

But if we are at point we can introduce new keywords/syntax in the language, it would just as well possible to come with something like

  a.chain(b, c)

In case you need to pass parameters

  a.chain([b, p1, p2], c)

And for the latter case

  const indexes = (function* () {
    for (let i = 0; i