> It ultimately resulted in a loop counter overflowing, which recomputed the same thing a billion of time (but always the same!). So the visible effect was a request would randomly take 3 min instead of 100ms.

This means that multiple goroutines were writing to the same local variable. I've never worked on a Go team where code that is structured in such a way would be considered normal or pass code review without good justification.

It happens all the time sadly.

It's not because people intentionally write this way. A function takes a parameter (a Go slice for example) and calls another function and so one. Deep down a function copies the pointer to the slice (via closure for example). And then a goroutine is spawned with this closure.

The most obvious mistakes are caught quickly. Buu sharing a memory address between two threads can happen very indirectly.

And somehow in Go, everybody feels incredibly comfortable spawning millions of coroutines/threads.