3 ms·

> Even if they didn't randomize, unless they also explicitly guaranteed stable map order across versions, you DO need to sort the map if you want reproducibilit

by kokada 2y ago

> Even if they didn't randomize, unless they also explicitly guaranteed stable map order across versions, you DO need to sort the map if you want reproducibility. Author here. The particular case where this behaviour took me by surprise was when I wanted to print all available options from a toy CLI program that I wrote. I defined the options in a map (that had a function handler as a value) and didn't care about the order at all, but at least I expected the print order to be stable. So it took me by surprise when I ran the program 3 times and the order changed. First I thought I did something wrong, then I found the issue after some search. Now, it can be argued that this behaviour was good because I ended up sorting the values before printing, and now they have a predictable order. But I still think this was that kind of code that I didn't have to write (thanks to how Go works, I need to create a separate list and sort it instead; I think it is better with iterators in Go 1.23 though). > Because if you relied on it being conveniently stable within the same Go version, with no guarantees, your program would still be broken (reproducibility wise), if they changed the hashmap implementation. Well, not in this particular case. I just wanted it to print it in a stable way between multiple runs of the program. Again, maybe this whole thing helped me write a better program. But I still feel that it is unnecessary, and would prefer to just use a orderedmap instead.

randomdata 2y ago
> But I still feel that it is unnecessary So did Go in the early days, which quickly proved to be problematic. Randomization was eventually added to try and call attention to buggy (in the typical case; yours may be an exception) code.
lelanthran 2y ago
> I defined the options in a map (that had a function handler as a value) and didn't care about the order at all, but at least I expected the print order to be stable. But that means that you did care about the order. You may not have cared what it was, but you cared that it existed. IOW, you relied on the order. In any hashmap, it's a given that you cannot rely on the order. Some languages may explicitly give you those guarantees but that is separate from the prescription for 'hashmap'.
- kokada 2y ago
  I think you're nitpicking about semantics, but ok. > In any hashmap, it's a given that you cannot rely on the order. Again, any order was fine, as long it was stable (it could be even stable between compiled versions, if Go say, add a salt during compilation). The weird part here is that it changed between runs.
  - pests 2y ago
    It was stable for any one run :D Is this just not human desires projecting extra requirements? You say you don't care about order, but then you clarify that you do want them to be stable between runs. Those are not the same thing. To a computer without judgement, any order is fine. The first run is somehow blessed by you, so any runs after seem off or weird. If it didn't actually matter to a computer, it wouldn't care if it was different each run.
    - kokada 2y ago
      > It was stable for any one run :D Not even that, because if you iterate multiple times you get random order in each different iteration: package main func main() { m := map[string]bool{"foo": true, "bar": false, "baz": true, "qux": false, "quux": true} for range 5 { for k := range m { println(k) } println() } } $ go run ./main.go bar baz qux quux foo foo bar baz qux quux qux quux foo bar baz baz qux quux foo bar quux foo bar baz qux > You say you don't care about order, but then you clarify that you do want them to be stable between runs. Being stable between runs doesn't mean I want a specific order. Slightly different things. > Those are not the same thing. To a computer without judgement, any order is fine. The first run is somehow blessed by you, so any runs after seem off or weird. If it didn't actually matter to a computer, it wouldn't care if it was different each run. If you want to argue about how computers work, remember that computers are bad at doing random things, this is why they need special hardware to do so. The fact that Go goes as far to actually randomise each iteration is the surprising thing here, making iteration unstable, and not the fact that iterating between hash maps values are random.
thcoldwine 2y ago
SQL does not guarantee the order, as well as go but we don’t complain about this in SQL :) Some things needs to be accepted and I am actually glad go does randomization of the order — it makes programs more robust if the backing storage of the map will change in the future. Having better data structures in stdlib will be beneficial, but we just got iterators so this will follow in 1-3 years time I believe. I would prefer to not have generics in the language personally, but luckily they’re not that common in the codebases anyways.

by kokada 2y ago

randomdata 2y ago

> But I still feel that it is unnecessary So did Go in the early days, which quickly proved to be problematic. Randomization was eventually added to try and call attention to buggy (in the typical case; yours may be an exception) code.

lelanthran 2y ago

> I defined the options in a map (that had a function handler as a value) and didn't care about the order at all, but at least I expected the print order to be stable. But that means that you did care about the order. You may not have cared what it was, but you cared that it existed. IOW, you relied on the order. In any hashmap, it's a given that you cannot rely on the order. Some languages may explicitly give you those guarantees but that is separate from the prescription for 'hashmap'.

kokada 2y ago
I think you're nitpicking about semantics, but ok. > In any hashmap, it's a given that you cannot rely on the order. Again, any order was fine, as long it was stable (it could be even stable between compiled versions, if Go say, add a salt during compilation). The weird part here is that it changed between runs.
- pests 2y ago
  It was stable for any one run :D Is this just not human desires projecting extra requirements? You say you don't care about order, but then you clarify that you do want them to be stable between runs. Those are not the same thing. To a computer without judgement, any order is fine. The first run is somehow blessed by you, so any runs after seem off or weird. If it didn't actually matter to a computer, it wouldn't care if it was different each run.
  - kokada 2y ago
    > It was stable for any one run :D Not even that, because if you iterate multiple times you get random order in each different iteration: package main func main() { m := map[string]bool{"foo": true, "bar": false, "baz": true, "qux": false, "quux": true} for range 5 { for k := range m { println(k) } println() } } $ go run ./main.go bar baz qux quux foo foo bar baz qux quux qux quux foo bar baz baz qux quux foo bar quux foo bar baz qux > You say you don't care about order, but then you clarify that you do want them to be stable between runs. Being stable between runs doesn't mean I want a specific order. Slightly different things. > Those are not the same thing. To a computer without judgement, any order is fine. The first run is somehow blessed by you, so any runs after seem off or weird. If it didn't actually matter to a computer, it wouldn't care if it was different each run. If you want to argue about how computers work, remember that computers are bad at doing random things, this is why they need special hardware to do so. The fact that Go goes as far to actually randomise each iteration is the surprising thing here, making iteration unstable, and not the fact that iterating between hash maps values are random.

thcoldwine 2y ago

SQL does not guarantee the order, as well as go but we don’t complain about this in SQL :) Some things needs to be accepted and I am actually glad go does randomization of the order — it makes programs more robust if the backing storage of the map will change in the future. Having better data structures in stdlib will be beneficial, but we just got iterators so this will follow in 1-3 years time I believe. I would prefer to not have generics in the language personally, but luckily they’re not that common in the codebases anyways.