Go concurrency considered harmful
Sargun Dhillon

You more or less answered your own questions… The solution is to use locks when it’s easy, and to use channels when you need to orchestrate multiple go-routines.

Finalizers should not be relied on. They’re there as a backup, but in your case, if you really want a go-routine for your map, using `.Close()` is appropriate. People use them to release cgo resources when a Go object gets garbage collected, but it’s more there as a band-aid because debugging such cgo leak issues are difficult. Generally, don’t use finalizers.

Regarding your criticism of SyncMap, all you need to do is embed it in another type w/ methods that accepts the particular type you want, but otherwise doesn’t expose the SyncMap. Inside the implementation it would technically be runtime type-checking, but in practice it wouldn’t matter because you’re not using the map for anything else.

Your comment about mutable slices and safety is spot on. Here’s a proposal for Go2, please take a look.

I wish you’d change your title. What’s bad is not go concurrency, but an incomplete type system. But they’re working on it, and we’ll get there. I consider misleading titles harmful. :)