Asynchrony is not concurrency

Disagreement over definitions

• Many comments dispute the article’s definitions of asynchrony, concurrency, and parallelism.
• Formal models (Lamport, CSP) are cited:
  • Concurrency is often defined in terms of partial orders and causality (“can these events affect each other?”) rather than “multiple tasks at a time”.
  • Parallelism is physical simultaneous execution; concurrency is a property of the program or model, not of hardware.
• Some argue concurrency is a superset containing both parallelism and asynchrony; others insist concurrency and parallelism are orthogonal (program model vs execution model).
• Several note that “at the same time” is ill‑defined (whose clock?) and that everyday dictionary definitions are unhelpful in technical contexts.

What “asynchrony” should mean

• The article’s definition (“tasks can run out of order and still be correct”) is heavily criticized:
  • Many say this really describes independence or commutativity, not asynchrony.
  • Others define async as: non‑blocking submission of work with result collected later; or “explicitly structured for concurrency”.
• Multiple comments stress that async does not inherently mean “out of order”: APIs may guarantee FIFO ordering while still being asynchronous.
• Partial ordering examples (e.g., socket operations, file writes) are used to show that “order doesn’t matter” is too strong.
• Some propose using mathematical terms like commutativity or “permutability”, but others note they don’t capture partial orders or complex interleavings.

Zig’s async / asyncConcurrent design

• The core Zig idea: separate “asynchronous but may execute serially” from “requires concurrency”, allowing:
  • Async APIs callable from synchronous contexts.
  • Libraries that are polymorphic over sync/async environments.
• The client/server accept vs connect example is central and also confusing:
  • Several readers initially misread it as about parallelism; others point out contradictions between the definitions and the example.
  • Concern that asyncConcurrent is opaque and easy to misuse without re‑reading the article.
• Some praise the design as ingenious and promising; others call it premature and rhetorically driven by Zig’s API needs.

Practical concerns: races, testing, and real systems

• Debate over whether async “has all the pitfalls of concurrency”:
  • One side: async races (e.g., multiple in‑flight non‑idempotent operations) feel similar to threaded bugs.
  • Other side: lack of hardware‑parallel races makes async substantially easier to reason about.
• Several note that many ecosystems combine async with true multithreading, so mutexes and classic concurrency hazards still apply.
• Testing interleavings of async/concurrent code is highlighted as hard; suggestions include specialized test I/O backends with fuzzing or deterministic scheduling.

Terminology fatigue and value

• Some argue these distinctions (async vs concurrency vs parallelism) add little practical insight and often obscure real questions like “what operations can overlap?” and “what ordering is required?”.
• Others find the distinctions—especially “concurrency as programming model, parallelism as execution model”—very useful for reasoning and teaching.
• A recurring sentiment: the field badly lacks shared, unambiguous vocabulary, and this article both contributes and adds to the confusion.