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.
This proposal is a combination of three proposals to evolve Golang towards a more secure language that is robust…github.com
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. :)