Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Concurrency vs. RxJS

code.gdnetwork.co

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Go Concurrency vs. RxJS

#31

Post by aporetics »

arctek wrote: post #23
cyberax wrote: post #14

JS concurrency is crap. It should be shot and buried in a lead coffin. Debugging async code is pure hell. With Go, you have a normal debugger that can be used to step over the code. You can get normal stack traces for all threads if needed. There is a race detector that can catch most of unsynchronized object access. With JS? You're on your fucking own. You can't find out the overall state of the system ("the list of…

It's also unintuitive in the sense that if you are racing you usually want to discard/stop the other Promises that didn't finish in time. But the only real way to do this is to pass through an AbortController down into whatever networking/IO task (and your own code for that matter) is happening to "cancel" it that way. Otherwise you just end up with the result of the fastest Promise and the rest will continue when th…

I thought the point of using observables over promises is that they have cancellation, and presumably an implementation of race would cancel any slower request (i.e., handle the abort controller automatically)? Is that not the case?

Re: Go Concurrency vs. RxJS

#32

Post by valenterry »

SkiFire13 wrote: post #18
phplovesong wrote: post #10

Earlier quoted context omitted.

I argue CSP is far superior to async/await in almost all cases. In Go errors are explicit and always right there. No weird control flow like you see in javascript.

CSP and async/await are perpendicular concepts. In fact you can have all combinations of them. Personally though I prefer either the actor model or structured concurrency to CSP, depending on the usecase.

I like a combination of both: actor model high level (basically, the business needs to understand the purpose/meaning of every actor) and then structured concurrency within each actor.

I've been trying to convince the gleam folks of that without too much success so far...

Re: Go Concurrency vs. RxJS

#36

Post by whazor »

steve_adams_86 wrote: post #25

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 w…

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.

Re: Go Concurrency vs. RxJS

#37

Post by styluss »

eknkc wrote: post #30
styluss wrote: post #29

Earlier quoted context omitted.

data, ok := If ok is false, the channel is closed and data is a zero value.

Whenever I used channels in Go, I regretted it at the end. Always have to look up "what happens when I do x and the channel is closed" kind of stuff. Code becomes weird with all the selects and shit. I like sync primitives and good old collections.

Oh absolutely, whenever i use anything, I have to see how to integrate cancellation and now context is everywhere just for this.

It gets overly verbose because of "simplicity"

Re: Go Concurrency vs. RxJS

#39

Post by porridgeraisin »

eknkc wrote: post #30
styluss wrote: post #29

Earlier quoted context omitted.

data, ok := If ok is false, the channel is closed and data is a zero value.

Whenever I used channels in Go, I regretted it at the end. Always have to look up "what happens when I do x and the channel is closed" kind of stuff. Code becomes weird with all the selects and shit. I like sync primitives and good old collections.

Yeah, where I worked we rarely used channels directly in business logic. Most of our code looked like "do 5 different time consuming operations, some of them optional i.e can fail" and then combine them all appropriately depending on success/failure so we simply made a BoundedWaitGroup primitive using sync.WaitGroup and a channel to ensure the boundedness that gets used everywhere.
Post reply on HN