Why was Dart mentioned under the broadcast headline? I didn't quite get it.
It's a joke.
Go Concurrency vs. RxJS
51–57 of 57 posts
Re: Go Concurrency vs. RxJS
#52The JS examples don't seem too demonstrative to me. Especially for someone not very familiar with RxJS. Any time you're wrapping something with `from` or `of`, I raise an eyebrow export function pipeline(in$: Observable ): Observable { return in$.pipe( mergeMap(product => from(product.Images)), ); } Why use mergeMap at all here? Why not not just return in$.pipe( map(product => product.Images), ); I get that this is a…
The former pipeline takes in products, splits the images, and processes each one.
The latter pipeline would releases batches/arrays of images.
Re: Go Concurrency vs. RxJS
#53How can these even be compared? Go does concurrency on multiple CPU cores, and javascript one one. Go can so both IO and CPU bound tasks with the SAME way, and in javascript land you really dont do any CPU tasks async at all (makes no sense to do so).
The async implementation is not shown in the article, but could easily do a number of things such as
- http request with decoder information
- worker threads
Re: Go Concurrency vs. RxJS
#54I 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 w…
Agree, especially about the debugging part.
Re: Go Concurrency vs. RxJS
#55Learning RxJS made me a better programmer faster than anything since the Gang of Four Design Patterns book 20 years ago.
What did you use it for, specifically? A personal project, or did you work on something that already used it heavily? I’ve played with it, and it’s interesting, but I haven’t quite found a reason to use it yet.
I use it in several places in my company. Being able to compose multiple async streams of data is the best part.
One simple example is a scroll tracker. I needed to track a user’s scroll, determine the direction, and combine it with touch events.
I wrote a prototype using event handlers and the code descended into incomprehensible spaghetti pretty quickly. With RxJS I was able to implement it as a series of custom operators that were easy to write, test, and use.
Re: Go Concurrency vs. RxJS
#56Having worked extensively with both Go and RxJS, I’ve come to appreciate the distinct strengths each brings to the table, though I lean towards Go for its clarity in managing concurrency. RxJS, with its powerful operators and composability, makes handling complex asynchronous flows relatively succinct. But that same power can lead to hard-to-trace bugs when things go wrong, especially with the more subtle operators like switchMap and mergeMap. Go, on the other hand, offers a more explicit concurrency model through goroutines and channels, which can be less error-prone in larger systems if used judiciously. The trade-off for Go’s more explicit concurrency is that it can feel more verbose, but the payoff in long-term maintainability and debugging is hard to overlook. RxJS is still a great tool for certain problems, but in terms of reliability and ease of debugging, Go wins out for me in most cases.
Re: Go Concurrency vs. RxJS
#57Earlier quoted context omitted.
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 ea…
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.
well, I meant easy compared to alternative ways of dealing with (async) events.