[twic]

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:

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.

[jayd16]

You'll still have the structured concurrency calls but that's much better than pure callback hell.

[winrid]

They won't abandon async callback based code.

VT have too much memory overhead to be equivalent.

[winrid]

* for high performance stuff

you can still wrap the medium speed/slower stuff in virtual threads.

[za3faran]

Do you have a citation for that? Genuinely curious.

[winrid]

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.

[0] https://openjdk.org/jeps/444

[vips7L]

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?

[winrid]

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.

[kaba0]

Bullshit - reactive frameworks allocate a shit ton of helper classes.

[twic]

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.

[ackfoobar]

> The stack for the VT requires a heap allocation

One object per stack frame of a virtual thread is cheaper than one callback object per suspension point.

[winrid]

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.