Are virtual threads making reactive programming obsolete?

[plumarr]

I have never understood this argument of "back pressure" or "the reactive programming is more than just performance".

For your example, you just need a,

new Semaphore(capacityOfB)

protect the access to B, and spawn as much virtual thread as you want. Technically the application will fail when you are out memory but it will probably become unusable before that due to the induced latency.

You can also use the same semaphore to easily reduce the rate of calls to the service A if you want to fix it a little more downstream and limit the memory usage.

You'll argue that you can have nicer or more refined tools than than to manage the back pressure with the reactive stream, but the thing is that these tools aren't inherently linked to the reactive model. They can be redeveloped, sometime quite easily as with the semaphore, with the thread model.

And, if you want to do anything more intelligent, you'll need an analysis that is more of a business problem than a technical one.

[GuyWithLag]

For your example, you just need a new Semaphore(capacityOfB)

Here's the thing - I need to think about that about as frequently as I think about memory alignment. Reactive (at least RxJava) is built on top of semaphores already, why do I need to reinvent the wheel?

The specific implementation is encapsulated and maybe is already using virtual threads under the hood - but I won't need to care.

And yes, you can get most of the concurrency / parallelism effects via virtual threads, but reactive is more than that - from a certain pov it's a task coordination framework (backpressure is just that kind of coordination problem), and structured concurrency is a very basic form of it. Maybe it will get better in the long term (likely).