Comment

Comment by mcqueenjordan

It's my own weird little take, but I'll share it.

In my experience, simple concurrency is easy. Confused concurrency is exceptionally hard.

I think about this in the same way I think about C++. C++ is quite nice, if your teams limit themselves to a reasonable subset of the language. But it can become an absolute monster of cumbersome complexity, if these guardrails go away.

Concurrency feels the same. If you take a certain view on concurrency, which is "do it as simply as possible, don't break certain rules, don't try to be too clever," I find it fairly straightforward to reason about.

At the same time, 9 out of 10 of the hardest things I've debugged have always been nasty, awful concurrency bugs. The reason it was so hard? The concurrency was complicated, interwoven, assumption-laden, and absolutely impossible for anyone to reason about. Implicit contracts between calls required entire whiteboards of non-trivial state to understand, and even then, with all that work, it was a needle in a haystack.

I guess I would just say: It doesn't have to be hard. It's only hard if you don't respect it from the beginning.

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton