3 ms·
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 s
by twic 3y ago
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 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 3y agoYou'll still have the structured concurrency calls but that's much better than pure callback hell.
- winrid 3y agoThey won't abandon async callback based code. VT have too much memory overhead to be equivalent.
- winrid 3y ago* for high performance stuff you can still wrap the medium speed/slower stuff in virtual threads.
- za3faran 3y agoDo you have a citation for that? Genuinely curious.
- winrid 3y agoThe 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 https://openjdk.org/jeps/444
- kaba0 3y agoBullshit - reactive frameworks allocate a shit ton of helper classes.
- twic 3y agoI'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.
- vips7L 3y agoBut 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 3y agoWell 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.
- ackfoobar 3y ago> 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 3y agoI 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.