If I run it locally it's not consistent:
go run lock/main.go
[3 0 1 2 5 4 6 9 7 8] 10⏎
go run lock/main.go
[1 5 6 7 8 0] 6⏎
go run lock/main.go
[0 3 1 2 4 5 6 7 8] 9⏎
The issue is that appending to slices concurrently is not safe, so you have to use a lock around the append or similar.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
I'm a beginner at rust, but this is the version I came up with that compiles and works:
https://play.rust-lang.org/?version=stable&mode=debug&editio...
I found this helpful: https://youtu.be/29LLRKIL_TI?t=1340
> Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time.
Also that for most uses a concurrent map is way overkill, and a thread-safe one is both costly and basically useless (hence the Java folks not keeping the thread-safety when migrating from Hashtable to HashMap).
On the other hand they're kinda shit given how awful non-builtin data structures are in Go, and how easy it is to "leak" maps between goroutines.
Be careful relying on the results of the Go playground; it has a bunch of differences and probably has GOMAXPROCS set to 1, which most other systems will not.
You need a sync.Mutex or similar protecting your call to append :)
> More on-topic, channels have their own tradeoffs. I often reach for WaitGroups and mutexes instead of channels, because things can get complicated fast when you're routing data around with channels
You're absolutely right. I certainly didn't intend to give a blanket recommendation. It's more of a, "If you're sharing memory, might it become clearer if you share memory by communicating?" I was worried that the simplistic examples would not properly represent the cases I was thinking of. I think that's a communication error on me.