4 ms·

I apologise for expecting better of language designers. After all, the solutions to these sorts of issues has only been around for a couple of decades. Far too

I apologise for expecting better of language designers. After all, the solutions to these sorts of issues has only been around for a couple of decades. Far too soon.

jrockway 11y ago
All the language designer can do is throw in a lock that you may or may not need if you're already locking properly. ConcurrentModificationException is nice, but comes at a performance cost.
alkonaut 11y ago
This is a library thing, not a language thing. And it's a performance tradeoff: they could have shipped with a concurrent map only, that is 1/10 as fast as the current one, but never causes a data race. However everyone that isn't doing anything concurrently would be paying for it. Not very clever. I trust the class library designers thought this through. They reached the same conclusion as pretty much every other library designer in every other language. For the same reasons.
- titzer 11y ago
  Data races are not the same thing as non-atomic accesses.
  - alkonaut 11y ago
    Sorry, I interpreted the statement as being about concurrency in maps, not about atomicity.
netheril96 11y ago
You are not expecting better. You are expecting worse. Plenty of use cases involve maps without concurrent modification, e.g., when used as a local variable. Your "better" version of maps will slow down all of them.
lazyjones 11y ago
The explanation for this design decision is reasonable IMHO: https://golang.org/doc/faq#atomic_maps https://golang.org/doc/faq#atomic_maps