5 ms·
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 t
by tejasmanohar 9y ago
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.
- TheSwordsman 9y agoI'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.
- helper 9y agoIts 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.
- pjmlp 9y agoUntil 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.
- kasey_junk 9y agoThere 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.
- pjmlp 9y agoWhich leads to the question when would they stop adding special case structures?
- kasey_junk 9y ago(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.
- dullgiulio 9y agoAlthough 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.