Most of the dimensions exist in the threaded world as well, only the dimensions wasn't as explored at that point so the choices are usually not what would have been chosen today.
Both efforts, instead of trying to avoid threads because they are expensive, simply asked why they have to be expensive and then made them not expensive.
100% sure - Java just has to store and process more than a simple state machine, also if all threads are busy with compute bound work, async work is stalled if you don't put the compute bound work on adedicated thread (pool)
How does parallelism come into play for this conversation? Async/await is a concurrency construct. And Java’s virtual threads are also a concurrency construct. Neither of them have anything to do with parallelism. Or am I misunderstanding something?
I'd say Java's virtual threads are also a parallelism construct (at least in the performance sense, not logical guarantees), since they're scheduled on a pool.
Comments
or, Java Virtual Threads and chill.
Most of the dimensions exist in the threaded world as well, only the dimensions wasn't as explored at that point so the choices are usually not what would have been chosen today.
Also formerly known as goroutines
Both efforts, instead of trying to avoid threads because they are expensive, simply asked why they have to be expensive and then made them not expensive.
they are still more expensive than compiled async await, also mixing compute and io-bound work can cause issues
How sure are you? Got a benchmark?
100% sure - Java just has to store and process more than a simple state machine, also if all threads are busy with compute bound work, async work is stalled if you don't put the compute bound work on adedicated thread (pool)
No. Because concurrency vs parallelism
How does parallelism come into play for this conversation? Async/await is a concurrency construct. And Java’s virtual threads are also a concurrency construct. Neither of them have anything to do with parallelism. Or am I misunderstanding something?
I'd say Java's virtual threads are also a parallelism construct (at least in the performance sense, not logical guarantees), since they're scheduled on a pool.