[samus]

> I'd go even further and say it'll be a net-loss in most cases, especially with modern complications like heterogeneous compute. If you're use case is specifically spinning up thousands of threads for IO (aka, you're a server & nothing else), then sure. But if you aren't there's no win here, just complications (like times when you need native thread isolation for FFI reasons, like using OpenGL)

Virtual threads are going to be an /option/, not a requirement. Threads have to explicitly created as virtual threads. If this is not done, nothing will change.

[cbsmith]

Having it be optional increases, not decreases, complexity. ;-) It also increases the propensity for people to use the feature blindly.

[samus]

For the JVM developers for sure. Implementing Project Loom must have been quite a ride. But even if it is used blindly, there are only three obvious issues I see:

* It's a no-no for computational workloads. As you said, they are concurrent, but not necessarily parallel.

* As you said, care has to be taken to use the right thread when interacting certain low-level APIs.

* It becomes easier to overload upstream systems by sending too many queries concurrently.

[cbsmith]

Oh there's a bunch of other problems as well. Developers will "solve" problems by increasing the number of virtual threads, that actually should be solved in other ways. Tons of code is going to suddenly discover assumptions about its underlying runtime model are no longer true, leading to subtle and potentially complex problems. New software will need to either take on the burden of choosing a runtime model or adopt the complexity from having to consider a mixture of both...