3 ms·
So what's your complaint? That you want a synchronized map? Then write a two line function that wraps your native golang typed mapped with sync.Mutex and be don
by nicpottier 9y ago
So what's your complaint? That you want a synchronized map? Then write a two line function that wraps your native golang typed mapped with sync.Mutex and be done with it.
If you are sharing a map in this way across many goroutines you are probably "doing it wrong" in go anyways.
- pjmlp 9y agoThat is how I used to code in the old days, still on MS-DOS, we are way past those basic type systems.
- pdimitar 9y agoI can see your point but you're generalizing a bit. For many people they work, for many others they don't. The old and the new type systems both have their place and use-cases.
- TheDong 9y agoThe new type system is a superset of the older ones. You can still write your own specialized error-prone repetitive containers for each and every type by hand. Yet, once a language has generics, people don't use the old way even though it's still possible to. Perhaps that's because it has no place when there's a replacement which is less error-prone, less repetitive, more usable, and can be implemented once in a library and used forever.
- pdimitar 9y agoI don't disagree. The risk is there. It's just that for me and others in this thread it's at an acceptable level. Outside of that, agreed.
- ngrilly 9y ago> Then write a two line function that wraps your native golang typed mapped with sync.Mutex and be done with it. Two lines? I think you underestimate what's going on in sync.Map: https://github.com/golang/go/blob/master/src/sync/map.go https://github.com/golang/go/blob/master/src/sync/map.go