To prevent these kinds of bugs, the iteration order in a Go map is randomized across each execution.
This was previously a special object (collections.OrderedDict) but is now the default behavior of every dict:
https://docs.python.org/3/library/collections.html#ordereddi...
Infuriatingly, this behavior is _not_ preserved for the set type.
if anything, it should be an another type, but this would also be against the go philosophy.
...which is completely fine. it isn't very difficult to work around and keeps the language simple, even if i'd prefer to have the option built-in.
This kind of behaviour should be visible on the application design and not depend on implementation details.
Not really since it’s Go (“lol no generics”): there’s no easy way to swap the builtin hashmap for an other associative array with deterministic behaviour and you will lose something (definitely performances, likely either convenience or type-safety, possibly both).
Yes it sucks not having generics, why should the built-in contribute to bad practices of relying into interaction behaviors, thus cripling any performance improvements to the data structure?
If you need ordered iteration to stay deterministic, extract the keys, sort them, then iterate over the (now-sorted) slice of keys?
If the order matters, you should defensively make SURE you are iterating in that order. If the order doesn't matter, the fact that each iteration over the map is different helps you not fall into a "I know this" trap.
"Shift left" just means that you shift the feedback to the developer farther left in the build process, closer (in time and space) to when the mistake was made.
Which turns out to be pretty inconvenient in Go. So more likely you’d do something like copy the keys to a slice, sort the slice, then iterate that to get the map values.
Incidentally, that’s exactly what the json package does when encoding a map.
For evidence, see:
https://github.com/golang/go/issues/6719