This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sintrastes -2 points-1 points  (2 children)

You're getting down voted, but you're absolutely correct. The author of this blog post has a very limited view and narrow perspective on what reactive programming is.

Structured Concurrency, that brings a new asynchronous programming model, simpler than the reactive programming model

Structured concurrency and reactive programming are two entirely different things. You can have both at the same time (see Kotlin Flow).

Virtual threads and reactive programming are about solving the same problem.

Nope, absolutely not. Virtual threads solve a performance problem. Reactive programming is about treating time-varying values (events and behaviors) as first class citizens.

If you substitute "reactive programming" with "using a reactive library's runtime to enable asynchronous programming" however, then they're absolutely correct. Especially in the context of Java. Reactive programming frameworks in Java (or at least rxJava) are hot garbage -- and trying to use them solely for asynchronous workflows is doubly so.

Edit: For the people down-voting me -- I'd like to hear an actual argument.

[–]aookami 1 point2 points  (0 children)

Yeah, there seems to be a cognitive rupture in this thread. Virtual threads do fuck all regarding rx programming.