This is interesting, we used RxJava quite a bit on Android until Kotlin Coroutines made things a bit easier in that the code read more linearly and worked nicely with built in language features like exceptions for error handling.
Just curious if you agree with this in Java, or had other reasons.
It colors your entire code base, prevents natural error handling, and quite frankly makes maintenance that much more complex.
Obviously there’s a place for it, but every project I’ve been on that used it shouldn’t have.
Do virtual threads make reactive within that model unnecessary too? Seems maybe not? Reactive is both a model, and a paradigm, no?
Even with virtual threads, there will still be a reason to write reactive programs it seems.
I work on moderate sized async reactive pipeline with lots of CompletableFutures throughout (and chaining of them so you can process a batch in parallel and commit contiguous offsets periodically) and there's several bugs that have been undebuggable because they happpen _infrequently enough_ in prod, the heap dump is huge, and there's no stack trace to tell you what is going on. The best you can do is lots lots and lots of logging and turn it into an analytics problem to find out what happened (to be fair, logging is only marginally better than wading through a heap dump of completable futures).
I've made my fair share of completable future messes with a lot of biconsume/thenApply/handle nonsense to try and avoid blocking.
The only difference is virtual threads have platform support which means even better stack traces and no need to decorate your method.
So yup, agree.