I think the biggest impact of virtual threads is that the ecosystem will abandon asynchronous APIs. No more futures, callbacks, servers where you have to make sure not to block the thread, reactive frameworks, etc. Just nice simple imperative blocking code. Nima is the first example i've seen:
We've had two production bugs in the last two weeks caused by handlers blocking the server thread in apps using an async web framework, which would simply not have happened with a synchronous server.
The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway.
But what’s more expensive, some more ram? Or the hours upon hours upon hours wasted in dev salaries trying to develop and debug reactive code?
Also is that VT allocation more than all of the extra allocations from reactive frameworks internally? Or all of the heap capturing lambdas that you pass to reactive libraries? Do you have a source comparing any of this?
Well I'm one person running several reactive services for fastcomments right now and I have no issues... so in my case the ram is more expensive :p but I am looking forward to benchmarks.
I'd definitely be interested to see some benchmarks of real-world code, once virtual threads and its attendant web frameworks have had a year or two to mature.
I guess I'm thinking of cases where I would invoke a virtual thread from a reactive framework per request in which case you need the callback regardless. I guess if you can do away with that then, maybe. I need to benchmark it.
https://helidon.io/nima
We've had two production bugs in the last two weeks caused by handlers blocking the server thread in apps using an async web framework, which would simply not have happened with a synchronous server.