Agree the post is low content, but we can still take it as a discussion prompt. The author mentions concurrency problems, and rightly attributed the problem to

Agree the post is low content, but we can still take it as a discussion prompt. The author mentions concurrency problems, and rightly attributed the problem to concurrent manipulation of shared state. While the author addresses this with a technique—locks—commonly used in other concurrent systems such as threads, there’s another solution just sitting there begging to be noticed: don’t share state, or if you must share state make atomic changes. This solution is available in many forms (with significant conceptual overlap): - Pure functional programming - Immutable (sometimes persistent) data structures - Reducers - Reactive computation - Software transactional memory Plenty more I’m sure. This isn’t to say any or even all of them are a silver bullet, and each makes some trade offs (compute performance, memory overhead, ergonomics/DX) to some degree. But in quite a lot of cases, those trade offs are worth the benefit of not having to reason about shared state, race conditions, concurrent consistency at all. And they can also help you produce more maintainable and testable code.