The burden is on the programmer adding a new thread to know what they can safely access.

The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread.

Designs that spread complexity rather than encapsulate it are rarely a good idea.

> Designs that spread complexity rather than encapsulate it are rarely a good idea.

Exactly, globals spread complexity.

You need to look at the implementation of each function to know if you can call it. That’s the landmine.

I agree that dependent sequences of events, coordinated through a global are bad. But there are other usages which are not error prone. For example an allocation, logger, readonly settings, or a cache.

That’s sounds more like a weakness of the language: that preventing data races is not automatically tracked for you, no?

If you care about performance, many locks across many pieces of shared state is always a bad idea.

If you don’t care about performance and want safety you should be using processes. Explicit shared memory is safer than implicit.

and yes. Better thread management tools are always welcome when we can get them.