Hacker News Reader

Comment by helper | Hacker News Reader

When should one use sync.Map vs a plain old map with a RWMutex?

Probably the same with any other locked data structure vs. structure using atomic ops. If you have read-heavy workload, especially one that does batching then grabbing a read-lock once and executing your batches before releasing it can be faster than lots of reads on a current map. Especially on weakly ordered architectures where the ordered reads may cost you performance.

That makes sense. I was hoping someone would have some concrete benchmarks for different access patterns but I don't see any in the github issue[1].

[1]: https://github.com/golang/go/issues/18177

When one does not care about type safety ;)

Only sorta kidding... Personally, I think sync.Map is a dangerous addition to the standard library, and hope that the Go team does not encourage using the empty interface{}'s like this. I can only imagine how bad it'll feel when someone reads an int64 as an int.

I'd go further and say when one cares less about performance. There's overhead for type assertions that could be avoided by implementing your own synchronized map with the types you desire. Admittedly, the overhead is probably negligible for most users.

Its not really any different context.WithValue where the strongly encouraged idiom is to have all access go through typed get/set methods that handle the type casting for you.

Until they introduce some kind of type safe genericity language level support, interface{} and go generate are the only options available for generic data structures.

Personally I would already be happy with what CLU allowed for in 1975, no need for anything more expressive.

There is a third option which is to add specific data structures to the existing list of generic data structures with out making user defined generics.

Which leads to the question when would they stop adding special case structures?

(shrug) they clearly are ok with some generics. In my mind if they argued that they'd rather support more widely used data structures at the language level instead of user defined generics thats a logically consistent position.

In fact, if I could get a) a type safe concurrent map b) a promise/future construct and c) a fast concurrent queue for single writer multi-reader, I'd probably be ok with the set of generic data structures provided in the language.

If they fixed their variance rules along the way as well, I'd probably lose any actual arguments against the type system when it comes to the systems I build.

The question is of course, are those the only ones that fall into that category? Who knows but those are the ones I run into the most pain for.

Although I agree with you about encouraging interface{} (there is even a "proverb" against its usage), you cannot read an empty interface as a type it is not.

Unlike C void-pointer, interface{} is the tuple (type, value) and you need a type assertion for the right tipe to get the value.

generally don't want to use RWMutex unless you can help it; the performance is much worse than the regular sync.Mutex

Reply on news.ycombinator.com