Having 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.
I my experience, its something that starts with trust, a lot of times you would have trust what a dev is saying, but still asking questions, asking why an estimate on a task is what is being proposed, why would it take more effort, what are the alternative ways of doing it etc. Too much agreement on everything and complete lack of agreement are both signs of something not right. Healthy debates are good