Hi Arnaud,

The point is that platform threads are limited (not to 100, but let's say to 10,000). At some point they will make your operating system unstable and crash your computer (you can find several presentations on virtual threads where the presenters crashed their computers trying to figure out how many platform threads they can start).

Let's say we don't have 1,000 tasks, but 1,000,000.

Then we cannot use `newCachedThreadPool()` or `newThreadPerTaskExecutor(...)` - because trying to create 1,000,000 threads will pretty quickly crash your computer. So let's use `newFixedThreadPool(10_000)` to be safe.

Running 1,000,000 tasks on a pool of 10,000 platform threads will take 100 seconds.

But running the same amount of tasks on a `newVirtualThreadPerTaskExecutor()` will only take a bit more than a second - maybe 2 or 3 seconds with all the overhead - but far less than 100 seconds.

Best wishes
Sven

A) They allow you to write code in the traditional blocking "thread-per-request" manner. This is familiar to any developer and is easily maintained even by developers who are not pros at asynchronous programming. Also, code written this way does not need to be rewritten to asynchronous code in order to scale.

B) The program is easier to profile and debug because on the stack, you see your code, and not mainly the asynchronous framework's code.