The font colors make this unreadable.
If you’re in light mode it helps a bit.
I’m doom scrolling at midnight. No way I’m going to flashbang myself
Go Concurrency vs. RxJS
11–20 of 57 posts
Re: Go Concurrency vs. RxJS
#12The font colors make this unreadable.
Switching to reader mode makes the text readable but code samples a mess. Can’t win
Re: Go Concurrency vs. RxJS
#13How 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).
90% of Go code isn’t CPU bound so that’s irrelevant.
Re: Go Concurrency vs. RxJS
#14JS 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 all threads"), without getting deep into the guts of React or whatever framework you're using. Debugger is useless, as each `await` call drops you into the event loop. So pretty much every complicated non-trivial JS app ends up with _tons_ of race conditions, by depending on the order of async functions finishing.
Speaking of race conditions. Coming from classic multithreading and Go, I tried to use `Promise.race` to simulate the `select` statement. Turns out that in JS it is actually useless because it LEAKS MEMORY BY DESIGN: https://github.com/nodejs/node/issues/17469
Back to the article. It uses pre-generics Go. In more modern Go, you can use something like Conc to reduce the boilerplate: https://github.com/sourcegraph/conc?tab=readme-ov-file
Re: Go Concurrency vs. RxJS
#15Concurrency 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.
So you prefer CSP to CPS?
Re: Go Concurrency vs. RxJS
#16Concurrency 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…
> Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be.
Channels in Go indeed could be better designed and more extensible. However, they are not the only way to use the Go concurrency. There are usual condition variables, mutexes, etc.
Re: Go Concurrency vs. RxJS
#17How 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).
90% of Go code isn’t CPU bound so that’s irrelevant.
????
Re: Go Concurrency vs. RxJS
#18Concurrency 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.
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.
Re: Go Concurrency vs. RxJS
#19RxJS is useful and overused whenever I've seen it.
Re: Go Concurrency vs. RxJS
#20The font colors make this unreadable.
Thought it was my phone..