Someone probably much better than me can correct me where I go wrong here, but I'll have a stab at this.
The way I think about it, is asynchronous programming gives you the tools to write programs that don't stop doing useful work while they're waiting for something to happen. If parallelism gives you more effective use of your CPU, asynchronous programming gives you more effective use of your time.
Let's presume you have a program that does some things, makes several requests to the network or requests several things from the file system, collects the results and carries on.
In a synchronous program, you would make each request, wait for it to come back (the program would block at this point), then when it's complete, proceed with the next request. If each request takes ~2 seconds to complete, and you've got 15 to make, you've spent most of that 30 seconds just idling, not actually doing anything.
In an asynchronous program, you could submit those requests all at once, and then process them as they came back, which means you only spend about ~2 seconds waiting before you start doing useful work processing the results. Even if your program is single threaded and you can only actually process one item at a time, you've made more efficient use of your time.
Some murkiness comes in the intersection of the 2 and how it's implemented in various languages. For example, you could also dispatch each of those requests out to a thread, and if you returned all the results to the main thread before processing them you'd have the same result and near the same performance as the async example (+- thread dispatch overhead etc etc). The power and advantage comes when you can use both to their advantage: you can't necessarily dispatch threads forever, because the overhead will impact you, and you can saturate your CPU. On the flip side, making something asynchronous that actually requires CPU work won't net any benefits because the work still has to be done at some point. Asynchronous programming gives you a way to move things around to maximise your efficiency, it doesn't actually make you go faster.
JS and Python are single threaded with event-loops, Rust organises chains/graphs of async code into state machines at compile time and then lets the user decide exactly how it should be run (I'm fairly this is correct, but if I'm wrong someone let me know).
Dotnet to the best of my knowledge lets your write "tasks" which are usually threads behind the scenes (someone please correct me here).
I don't know what Java uses, but I imagine there's a few options to choose from.
Haskell performs magic as far as I can tell. I don't know how it's model works, but I did once come across a library that appeared to let you write code and it would automatically figure out when something could be async, rearrange calls to make use of batching, automatically cache and reuse similar requests and just generally perform all kinds of Haskell wizardry.
The way I think about it, is asynchronous programming gives you the tools to write programs that don't stop doing useful work while they're waiting for something to happen. If parallelism gives you more effective use of your CPU, asynchronous programming gives you more effective use of your time. Let's presume you have a program that does some things, makes several requests to the network or requests several things from the file system, collects the results and carries on.
In a synchronous program, you would make each request, wait for it to come back (the program would block at this point), then when it's complete, proceed with the next request. If each request takes ~2 seconds to complete, and you've got 15 to make, you've spent most of that 30 seconds just idling, not actually doing anything.
In an asynchronous program, you could submit those requests all at once, and then process them as they came back, which means you only spend about ~2 seconds waiting before you start doing useful work processing the results. Even if your program is single threaded and you can only actually process one item at a time, you've made more efficient use of your time.
Some murkiness comes in the intersection of the 2 and how it's implemented in various languages. For example, you could also dispatch each of those requests out to a thread, and if you returned all the results to the main thread before processing them you'd have the same result and near the same performance as the async example (+- thread dispatch overhead etc etc). The power and advantage comes when you can use both to their advantage: you can't necessarily dispatch threads forever, because the overhead will impact you, and you can saturate your CPU. On the flip side, making something asynchronous that actually requires CPU work won't net any benefits because the work still has to be done at some point. Asynchronous programming gives you a way to move things around to maximise your efficiency, it doesn't actually make you go faster.
JS and Python are single threaded with event-loops, Rust organises chains/graphs of async code into state machines at compile time and then lets the user decide exactly how it should be run (I'm fairly this is correct, but if I'm wrong someone let me know). Dotnet to the best of my knowledge lets your write "tasks" which are usually threads behind the scenes (someone please correct me here). I don't know what Java uses, but I imagine there's a few options to choose from. Haskell performs magic as far as I can tell. I don't know how it's model works, but I did once come across a library that appeared to let you write code and it would automatically figure out when something could be async, rearrange calls to make use of batching, automatically cache and reuse similar requests and just generally perform all kinds of Haskell wizardry.