The concepts of concurrency and parallelism are adjacent enough that they are often confused. A lot of languages provide basic concepts for both but use different frameworks for both. So the difference really matters in that case. Or the frameworks are just a bit low level and the difference really matters for that reason (because you need to think about and be aware of different issues).
I've been using Kotlin in the last few years. And while it is not without issues, their co-routines approach is a thing of beauty as it covers the whole of this space with one framework that is designed to do all of it and pretty well thought through. It provides a higher level approach in the form of structured concurrency, which is what Zig is dancing around here if I read this correctly (not that familiar with it so please correct if wrong) and not something that a lot of languages provide currently (Java, Javascript, Go, Rust, Python, etc.). Several of those have work in progress related to that though. I could see python going there now that they've bit the bullet with removing the GIL. But they have a bit of catching up to do. And several other languages provide ways that are similarly nice and sophisticated; and some might claim better.
In Kotlin, something being async or not is called suspending. Suspending just means that "this function sometimes releases control back to whatever called it". Typical moments when that happens are when it does evented IO and/or when it calls into other suspending functions.
What makes it structured concurrency is that suspend functions are executed in a scope, which has something called a dispatcher and a context (meta data about the scope). Kotlin enforces this via colored "suspend" functions. Calling them outside a coroutine scope is a compile error. Function colors are controversial with some. But they works and it's simple enough to understand. There's zero confusion on the topic. You'll know when you do it wrong.
Some dispatchers are single threaded, some dispatchers are threaded, and some dispatchers are green threaded (e.g. if on the JVM). In Kotlin, a coroutine scope is obtained with a function that takes a block as a parameter. That block receives its scope as a context parameter (typically 'this'). When the block exits, the whole tree of sub coroutines the scope had is guaranteed to have completed or failed. The whole tree is cancelled in case of an exception. Cancellation is one of the nasty things many other languages don't handle very well. A scope failure is a simple exception and if something cancelled, that's a CancellationException. If this sounds complicated, it's not that bad (because of Kotlin's DSL features). But consider it necessary complexity. Because there is a very material difference between how different dispatchers work. Kotlin makes that explicit. But otherwise, it kind of is all the same.
If inside a coroutine, you want to do two things asynchronously, you simply call functions like launch or async with another block. Those functions are provided by the coroutine scope. If you don't have one, you can't call those. That block will be executed by a dispatcher. If you want use different threads, you give async/launch an optional new coroutine scope with it's own dispatcher and context as a parameter (you can actually combine these with a + operator). If you don't provide the optional parameter, it simply uses the parent scope to construct a new scope on the fly. Structured concurrency here means that you have a nested tree of coroutines that each have their own context and dispatchers.
A dispatcher can be multi threaded (each coroutine gets its own thread) and backed by a thread pool, or a simple single threaded dispatcher that just lets each coroutine run until it suspends and then switches to the next. And if you are on the JVM where green thread pools look just like regular thread pools (this is by design), you can trivially create a green thread pool dispatcher and dispatch your co routines to a green thread. Note, this is only useful when calling into Java's blocking IO frameworks that have been adapted to sort of work with green threads (lots of hairy exceptions to that). Technically, green threads have a bit more overhead for context switching than Kotlin's own co-routine dispatcher. So use those if you need it; avoid otherwise unless you want your code to run slower.
There's a lot more to this of course but the point here is that the resulting code looks very similar regardless of what dispatchers you use. Whether you are doing things concurrently or in parallel. The paradigm here is that it is all suspend functions all the way down and that there is no conceptual difference. If you want to fork and join coroutines, you use functions like async and launch that return jobs that you can await. You can map a list of things to async jobs and then call awaitAll on the resulting list. That just suspends the parent coroutine until the jobs have completed. Works exactly the same with 1 thread or a million threads.
If you want to share data between your co-routines, you still need to worry about concurrency issues and use locks/mutexes, etc. But if your coroutine doesn't do that and simply returns a value without having side effects on memory (think functional programming here), things are quite naturally thread safe and composable for structured concurrency.
There are a lot of valid criticisms on this approach. Colored functions are controversial. Which I think is valid but not as big of a deal in Kotlin as it is made out to be. Go's approach is simpler but at the price of not dealing with failures and cancellation as nicely. All functions are the same color. But that simplicity has a price (e.g. no structured concurrency). And it kind of shovels paralellism under the carpet. And it kind of forces a lot of boiler plate on users by not having proper exceptions and job cancellation mechanisms. Failures are messy. It's simple. But at a price.
The idea behind Zig approach which is only being implemented is to extend concurrent code to be executable outside the coroutine context, making it trivially serializable when that's possible (thus the networking example).
In general, the heavy lifting should always be moved to the lower level infrastructure (compiler, standard library, RDBMS system in case of ACID guarantees...) — leaving developer his brainspace for the business logic.
This requires minimum "function coloring", and I'd prefer if Python took that approach instead.
I've been using Kotlin in the last few years. And while it is not without issues, their co-routines approach is a thing of beauty as it covers the whole of this space with one framework that is designed to do all of it and pretty well thought through. It provides a higher level approach in the form of structured concurrency, which is what Zig is dancing around here if I read this correctly (not that familiar with it so please correct if wrong) and not something that a lot of languages provide currently (Java, Javascript, Go, Rust, Python, etc.). Several of those have work in progress related to that though. I could see python going there now that they've bit the bullet with removing the GIL. But they have a bit of catching up to do. And several other languages provide ways that are similarly nice and sophisticated; and some might claim better.
In Kotlin, something being async or not is called suspending. Suspending just means that "this function sometimes releases control back to whatever called it". Typical moments when that happens are when it does evented IO and/or when it calls into other suspending functions.
What makes it structured concurrency is that suspend functions are executed in a scope, which has something called a dispatcher and a context (meta data about the scope). Kotlin enforces this via colored "suspend" functions. Calling them outside a coroutine scope is a compile error. Function colors are controversial with some. But they works and it's simple enough to understand. There's zero confusion on the topic. You'll know when you do it wrong.
Some dispatchers are single threaded, some dispatchers are threaded, and some dispatchers are green threaded (e.g. if on the JVM). In Kotlin, a coroutine scope is obtained with a function that takes a block as a parameter. That block receives its scope as a context parameter (typically 'this'). When the block exits, the whole tree of sub coroutines the scope had is guaranteed to have completed or failed. The whole tree is cancelled in case of an exception. Cancellation is one of the nasty things many other languages don't handle very well. A scope failure is a simple exception and if something cancelled, that's a CancellationException. If this sounds complicated, it's not that bad (because of Kotlin's DSL features). But consider it necessary complexity. Because there is a very material difference between how different dispatchers work. Kotlin makes that explicit. But otherwise, it kind of is all the same.
If inside a coroutine, you want to do two things asynchronously, you simply call functions like launch or async with another block. Those functions are provided by the coroutine scope. If you don't have one, you can't call those. That block will be executed by a dispatcher. If you want use different threads, you give async/launch an optional new coroutine scope with it's own dispatcher and context as a parameter (you can actually combine these with a + operator). If you don't provide the optional parameter, it simply uses the parent scope to construct a new scope on the fly. Structured concurrency here means that you have a nested tree of coroutines that each have their own context and dispatchers.
A dispatcher can be multi threaded (each coroutine gets its own thread) and backed by a thread pool, or a simple single threaded dispatcher that just lets each coroutine run until it suspends and then switches to the next. And if you are on the JVM where green thread pools look just like regular thread pools (this is by design), you can trivially create a green thread pool dispatcher and dispatch your co routines to a green thread. Note, this is only useful when calling into Java's blocking IO frameworks that have been adapted to sort of work with green threads (lots of hairy exceptions to that). Technically, green threads have a bit more overhead for context switching than Kotlin's own co-routine dispatcher. So use those if you need it; avoid otherwise unless you want your code to run slower.
There's a lot more to this of course but the point here is that the resulting code looks very similar regardless of what dispatchers you use. Whether you are doing things concurrently or in parallel. The paradigm here is that it is all suspend functions all the way down and that there is no conceptual difference. If you want to fork and join coroutines, you use functions like async and launch that return jobs that you can await. You can map a list of things to async jobs and then call awaitAll on the resulting list. That just suspends the parent coroutine until the jobs have completed. Works exactly the same with 1 thread or a million threads.
If you want to share data between your co-routines, you still need to worry about concurrency issues and use locks/mutexes, etc. But if your coroutine doesn't do that and simply returns a value without having side effects on memory (think functional programming here), things are quite naturally thread safe and composable for structured concurrency.
There are a lot of valid criticisms on this approach. Colored functions are controversial. Which I think is valid but not as big of a deal in Kotlin as it is made out to be. Go's approach is simpler but at the price of not dealing with failures and cancellation as nicely. All functions are the same color. But that simplicity has a price (e.g. no structured concurrency). And it kind of shovels paralellism under the carpet. And it kind of forces a lot of boiler plate on users by not having proper exceptions and job cancellation mechanisms. Failures are messy. It's simple. But at a price.