Thanks for the explanation. Forgive my lack of knowledge, but can it not be solved by using parallelism instead of concurrency/threads? I thought Go has first class primitives to be able to do this?

> parallelism instead of concurrency/threads.

What do you mean? These seem synonymous to me.

> I thought Go has first class primitives to be able to do this?

TBH I'm only 1 week into learning Go myself (coming from Java/Scala/JS/etc). But it looks like the article used what Go offers. They used the atomic package which says, "provides low-level atomic memory primitives useful for implementing synchronization algorithms."

https://golang.org/pkg/sync/atomic/

> What do you mean? These seem synonymous to me.

What I meant was similar to this talk: https://blog.golang.org/concurrency-is-not-parallelism where there is also a load balancer example around 20:20 and using go channels (the primitive I’m pertaining to)

Channels aren't a way to avoid mutexes/locking, they are just meant to be simpler to write & reason about. Channels are implemented using mutexes under the hood.

An increment like s.current++ isn't atomic either. If two threads increment simultaneously the value may only increase by 1.