We ditched both and rewrote our services in Kotlin. We never looked back. Coroutines FTW!
Go Concurrency vs. RxJS
21–30 of 57 posts
Re: Go Concurrency vs. RxJS
#22We ditched both and rewrote our services in Kotlin. We never looked back. Coroutines FTW!
Can you elaborate a bit more, so us ignorant people may share in your excitement? I've seen many people switch from JVM to Go, but I've not seen a lot of people switch from Go to JVM.
Re: Go Concurrency vs. RxJS
#23JS 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 they get a chance.
Re: Go Concurrency vs. RxJS
#24Compare the runtimes also and how easy it is to debug and maintain RxJS vs Go. The former is a nightmare to maintain.
Re: Go Concurrency vs. RxJS
#25I 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.
Re: Go Concurrency vs. RxJS
#26Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Though, I honestly find moderately complex Go code far easier to maintain than moderately complex RxJS code, having had both in my career at different times. That said I will admit that sometimes having the RxJS toolkit at your disposal makes solving some problems very easy. It's just that when I construct a…
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.
How do you handle errors when reading from a channel?
Re: Go Concurrency vs. RxJS
#27One strong point about RxJS is marble testing, I haven't found something similar for async systems with complex scenarios.
Re: Go Concurrency vs. RxJS
#28guy is using unbuffered channel and wonder why it working slow, lol
Re: Go Concurrency vs. RxJS
#29Earlier 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.
How do you handle errors when reading from a channel?
data, ok := If ok is false, the channel is closed and data is a zero value.
Re: Go Concurrency vs. RxJS
#30Earlier quoted context omitted.
How do you handle errors when reading from a channel?
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.