Comment by Mawr
14 hours ago
Arguably, being 10 years late to the party is pretty bad.
Just how Go adding generics to the language didn't magically fix the billions lines of non-generic Go code, adding virtual threads to Java didn't update its entire ecosystem to take advantage of them.
Meanwhile, the entire Go ecosystem from the beginning took advantage of goroutines, so all code you'll ever interact with will have excellent support for them.
If you make use of a 30 years of library that does simple blocking IO and you call that library from a virtual thread you literally have non-blocking behavior - so your "didn't update it's entire ecosystem" is plain wrong. It's also just a Thread, so even consuming virtual threads by old libs is just fine.
Also, what 'party'? There is java, go, Haskell and erlang with anything similar. The majority of programming languages don't have such a feature so it's pretty questionable use of word to "be late".
Trust me. That's a common argument used when java introduces new features. Wait you see the same argument once value classes come to jdk 28.
I find that very debatable. Spring Boot, for instance, is just one config line away from automatically using virtual threads in its handlers:
We also see library implementations switching to them.