> You need to protect your state by communicating with channels or using a lock.

But what are you protecting? Setting a value will not cause a map rebalance, and so long as you are just setting a new value (not incrementing or like) it should be an atomic operation. Locking is really slow, and if you can find safe ways to avoid it, it can be a good thing.

Another thread could 1) write to the same key. 2) cause a table expansion (or a shrink) which rehashes the whole table (in most implementations). Either case will cause a difficult to diagnose bug. Use a lock or communicate with channels instead. There may be other subtle things which can get corrupted under concurrent use. The map type in Go has never been implemented in a thread safe fashion so if you try and use it as such you will be in for a bad time.

There's nothing specified that setting a value won't cause a map rebalance or rehash. The implementation is allowed to change things under the hood.

Locks are actually really cheap in many instances; mutexes can Lock and Unlock millions of times per second as long as contention is low.

> so long as you are just setting a new value

The hash map first needs to determine whether it already has a value with such a key or not, which requires some checking that typically involves many instructions and is not atomic. And to determine that, you at least need a read-lock.