I think there's not much point trying to define these concepts as there is no consensus about what they mean. Different people have clear ideas about what each

I think there's not much point trying to define these concepts as there is no consensus about what they mean. Different people have clear ideas about what each concept means but they just don't agree. It's like integration tests vs unit tests... Most developers think they have a clear idea about what each one means, but based on my experience there is very little consensus about where the line is between unit test vs integration test. Some people will say a unit test requires mocking or stubbing out all dependencies, others will say that this isn't necessary; so long as you mock out I/O calls... Others will say unit tests can make I/O calls but not database calls or calls which interface with an external service... Some people will say that if a test covers the module without mocking out I/O calls then it's not an integration test, it's an end-to-end test. Anyway it's the same thing with asynchrony vs concurrency vs parallelism. I think most people will agree that concurrency can potentially be achieved without parallelism and without asynchrony. For many people, asynchrony has the connotation that it's happening in the same process and thread (same CPU core). Some people who work with higher level languages might say that asynchrony is a kind of context switching (as it's switching context in the stack when callbacks at called or promises resolved) but system devs will say that context switching is more granular than that and not constrained to the duration of specific operations, they'll say it's a CPU level concept.