Go Concurrency vs. RxJS

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 an RxJS pipeline that does some complex stuff end-to-end, don't expect me to be able to readily explain it a couple months later. It's not write-only... But it gets thick easily.

One issue I think people underrate that impacts both promises and RxJS is error handling. Exceptions in JS can be a lot of different things, including programming errors like TypeError; but most people will write error handling that doesn't actually distinguish the two cases. In fact it's hard to blame them as this can make for a lot of error-prone boilerplate to deal with, but it's especially annoying as it can hide programming errors in plain sight, making them hard to spot for your observability tooling and harder to debug (it's frequently not a possibility people give much thought to.)

Then again, on the Go end, I find it hard to try to handle async errors as well, though for totally different reasons. There's lots of good ideas floating around with Go and I even kind of like contexts to a degree, but it feels like there's no cohesive story that binds it all together. I used to use tomb, but I found myself wanting even more than it offered.