[steve_adams_86]

I always found RxJS fairly awkward. I assumed it was a skill issue (and I still think it is), but gradually learned it for personal and professional projects. It's fine. I avoid it now. I think Go is orders of magnitude better in terms of general concurrency tooling, though I know some people straight up hate it.

I've recently started using Effect, the TypeScript library, and I find it's so much better than RxJS as well. Now that I've gotten the swing of things, I can't imagine going back to RxJS. Although I prefer Go in many ways still, there are things about Effect I actually prefer over tooling in Go as well. And of course, there is no direct comparison (one is a library in a language that's a superset of another language, the other is just a language), but when it comes to solving the problem of concurrency, Effect is great. I recommend it.

Effect is also a lot more than RxJS. It has schema and data tools, primitives for error handling and control flow, state management, etc. Regardless, where they overlap, I think Effect is much better designed.

Where Effect (and RxJS) falls apart for me is debugging. I really hope that story improves. The errors in TypeScript are pretty brutal, and actually tracing through calls isn't as intuitive as it appears it will be at times. Weird stuff goes on. Things get convoluted quickly. Somehow that disadvantage hasn't prevented it from becoming a go-to tool for me, so far.

[whazor]

My biggest issue with RxJS is that it is so easy, that you can easily make pretty bad bugs. In particular, you can have a `mergeMap` or a `switchMap`, and with RxJS they are very similar in API. But if you pick the wrong one, it can lead to weird bugs in your application. However, if you would manually program promises and maybe debounce helpers, you would be more likely to program the correct behavior.

Still, the easiness RxJS is pretty cool, and if you are an expert at it, you could build complicated applications with very little code. Also Marble Testing is a cool way of testing certain application behaviors.

Overall, I would recommend searching decent alternatives. Since RxJS is too hard to get right.

[steve_adams_86]

Haha, after all this time I still don’t find RxJS easy unless I’m using it for a common, familiar pattern. I agree otherwise, though. It’s definitely easy to create weird bugs.

[whazor]

well, I meant easy compared to alternative ways of dealing with (async) events.

[kermerlerper]

Agree, especially about the debugging part.