@animeirl@shitposter.club
@mauve yep, you gotta import golang.org/x/exp/maps or write it yourself. Not great.
@mauve I'm not sure Rust has one either for hash maps (keys aren't stored in a predictable order so it wouldn't make that much sense) but there's probably one for btree maps.
@jeremy_list Interesting. No way to get an iterator for jusr keys either?
@mauve yes you can get an iterator for keys for both map implementations in the standard library but not one for keys in a certain range other than `.keys().filter(...)`
@jeremy_list that's reasonable. Afaik golang doesn't even have first class iterators in the std 😱
@mauve the #golang 1.21 release which will be released soon (days or weeks, it’s at rc3 currently I think) will include the `maps` module in stdlib, which includes a `Keys()` implementation: https://pkg.go.dev/maps@master#Keys
@fansipans Heck yeah, good to hear! I'm glad go has been improving over time.
@fansipans @mauve At least weeks; the scheduled release date is the beginning of the second week of August, but it could be later if they have to do another RC. https://go.dev/s/release
@lukeshu @fansipans ha
ha, I think I can deal with for loops until then. :P It's defs not ideal but also not all that bad.
@tnypxl honestly. Though I'm honestly overflowing with joy that modules are easy to work with now. Like the amount of pain I no loger have to deal with when using Go is magnitudes lower thanks to that.
That is to say maybe the other bits will get better eventually too.
Well i don't get it.
Get a list of keys from a map to iterate the keys-list instead of the map, doubles the mem and doubles the work.. I never had the case to need the list of keys of a map 🤔 without do something in a iterative way with it.
Do you have an example for this case ?
If this is a java-thing, then better use java 😆
@martinsstar in this case I am passing in an object with a dynamic set of fields to use in a query and I just need the set of keys to compare against other sets within database indexes.
is it faster to do a map loop each time instead of having this slice? I assumed it's more overhead to iterate the entire map instead of an array of keys. Honestly I just want a high level Set type to do unions and diffs.
@martinsstar the objects look kinda like this but more simple. https://www.mongodb.com/docs/manual/tutorial/query-documents/
@mauve
Well, i think do an range on maps will take the same time as range on slices.
Depending on the compare algo, maps can be faster if first look if the key exist ( seeking in a map is a way faster than seeking in a slice, see summary here: https://blog.devgenius.io/slice-and-map-performance-in-golang-b211027e6bed )
@martinsstar good to know. I'll try some benchmarking and profiling. :)
@mauve cool would be nice to know if my guess is right.
If two maps need to get compared, i would iterate the first map and look in the second if the key exist. So i guess using of maps will be faster ( because of the key lookup), than to create two arrays of keys and do the lookup there.
But i prefer to use a readable solution over an fast one 😉
Currently i have no time ( maybe tomorrow ) to do an benchmark about this. If you are faster, please inform us about your result 😎 👍
@mauve okay, programmers can not stop thinking about problems...
i do some benchmark of string-lookups in arrays or maps in #golang.
I take the worst case where the first string is not found in the second map/array ( this should only be the case if both objects are completely different )
maps: 41455 ns/op
arrays: 2283822 ns/op
But "iterate" over maps seems a little bit slower ( for 1000000000 ops )
range over maps: 0.0000098 ns/op
range over arrays: 0.0000005 ns/op
@mauve Coming in Go 1.21, in August: https://pkg.go.dev/maps@master#Keys
