[FpUser]

Developing good framework (does not have to be multi processing) is generally hard. Having decent subject understanding and knowing how to use said frameworks is not a rocket science. And there is a difference between "easy-peasy (tm)" and not being lazy and learning some basics

[Daishiman]

I’m sorry but I spent two semesters studying the theory behind concurrent data structures and formalizations of concurrent state machines and there is no way you can tell me that reasoning about multithreaded program state is easy.

[CHY872]

In fairness, concurrent data structures generally don’t represent what gp is talking about. Yes, very, very difficult to write a solid concurrent ring buffer. Writing Java’s concurrent hashmap - hard. Using it to implement a simple in memory kv store: not that hard.

But ensuring some parallelism while maintaining thread safety is straightforward in many contexts - an uncontended mutex is close to zero overhead. Languages like Rust make it harder to struggle with some of the thornier issues (data races which cannot be simulated by stepping threads).

E.g. in Java a typical system looks like a thread per request with some shared underlying data structures like caches or connection pools. Relatively easy to use these safely, or to guard some shared object with a synchronized.

Likewise with parallelism - a lot of problems just boil down to ‘do a few map reduces’ and the parallelism is pretty trivial.

Obviously, concurrent systems are fiendish to reason through - but there are a lot of cases where the complexity can be side stepped. Doesn’t seem to stop people writing scary code on the daily though.

[FpUser]

I spent lifetime (since the end of the 80s) programming concurrent systems among many other things. Think I can draw my own conclusions.

[Daishiman]

It shows; something that needs a lifetime to master is definitely not on my list of Easy(TM) things.