4 ms·

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

by 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.
  - lelanthran 2y ago
    > The fact that Go goes as far to actually randomise each iteration is the surprising thing here, I gotta be honest, having come to Go after having first programmed professionally for around 25 years, I have never run into this problem. My expectation for hashmaps was set decades ago, and it was set as "Thou Shalt Not Depend On The Order Of Hashmaps!" :-) Having used hashmaps via some obscure C library in the 90s, I quickly came to realise that I couldn't rely on the order - simply adding an element and then immediately removing it with no lines of code in between those two calls was enough, in some cases, to completely mess up whatever order I thought there was. My own OSS hashmap library, on github, specifically doesn't mention order, because I (maybe naively) assumed that everyone reaching for a hashmap already knows that the order isn't guaranteed to be stable at all, even if the hashmap is never modified by the caller in between reads.
    - kokada 2y ago
      > simply adding an element and then immediately removing it with no lines of code in between those two calls was enough, in some cases, to completely mess up whatever order I thought there was. Yes, this is what I expect too. But this is NOT what Go is doing here. Go is actually randomising the order EVERY time you try to iterate, even if you do NO manipulation of the items inside the map. See this comment thread for more details: https://news.ycombinator.com/item?id=41274850#41276274 https://news.ycombinator.com/item?id=41274850#41276274. This is the surprising part, not that the iteration order may change if you add/remove items. > My own OSS hashmap library, on github Does your hashmap library, say, have a `iterate()` method that randomises the order of items every time it is called? If yes, ok, we are talking about the same thing here. But I am almost sure that it does not, and this is what Go is doing here.
      - lelanthran 2y ago
        > Go is actually randomising the order EVERY time you try to iterate Which is 100% perfectly within specification of the hashmap concept. It may not match your expectation of what a hashmap is, but it is what it is, and that's what a hashmap is. IOW, there is no guarantee, and a library that randomises the order that it returns hashmap elements when iterating is perfectly correct!
wizzwizz4 2y ago
Without semantics, our programs are nothing.
lelanthran 2y ago
> Again, any order was fine, as long it was stable Understood, but that is not a guarantee of hashmaps. Hashmaps, by themselves, are a concept independent of any programming language. So, sure, I get that your expectations of a hashmap's behaviour was set by some programming language $FOO, and that it is reasonable to expect that someone who learned on $FOO has the expectation that a hashmap has a specific behaviour. But, that being said, after you learn that a hashmap is a concept independent of any programming language, and after you learned that that concept does not guarantee the behaviour you expect, it's signficantly easier to change your expectations for hashmap behaviour than to change the definition of the concept's guarantees.

by kokada 2y ago

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.
- lelanthran 2y ago
  > The fact that Go goes as far to actually randomise each iteration is the surprising thing here, I gotta be honest, having come to Go after having first programmed professionally for around 25 years, I have never run into this problem. My expectation for hashmaps was set decades ago, and it was set as "Thou Shalt Not Depend On The Order Of Hashmaps!" :-) Having used hashmaps via some obscure C library in the 90s, I quickly came to realise that I couldn't rely on the order - simply adding an element and then immediately removing it with no lines of code in between those two calls was enough, in some cases, to completely mess up whatever order I thought there was. My own OSS hashmap library, on github, specifically doesn't mention order, because I (maybe naively) assumed that everyone reaching for a hashmap already knows that the order isn't guaranteed to be stable at all, even if the hashmap is never modified by the caller in between reads.
  - kokada 2y ago
    > simply adding an element and then immediately removing it with no lines of code in between those two calls was enough, in some cases, to completely mess up whatever order I thought there was. Yes, this is what I expect too. But this is NOT what Go is doing here. Go is actually randomising the order EVERY time you try to iterate, even if you do NO manipulation of the items inside the map. See this comment thread for more details: https://news.ycombinator.com/item?id=41274850#41276274 https://news.ycombinator.com/item?id=41274850#41276274. This is the surprising part, not that the iteration order may change if you add/remove items. > My own OSS hashmap library, on github Does your hashmap library, say, have a `iterate()` method that randomises the order of items every time it is called? If yes, ok, we are talking about the same thing here. But I am almost sure that it does not, and this is what Go is doing here.
    - lelanthran 2y ago
      > Go is actually randomising the order EVERY time you try to iterate Which is 100% perfectly within specification of the hashmap concept. It may not match your expectation of what a hashmap is, but it is what it is, and that's what a hashmap is. IOW, there is no guarantee, and a library that randomises the order that it returns hashmap elements when iterating is perfectly correct!

wizzwizz4 2y ago

Without semantics, our programs are nothing.

lelanthran 2y ago

> Again, any order was fine, as long it was stable Understood, but that is not a guarantee of hashmaps. Hashmaps, by themselves, are a concept independent of any programming language. So, sure, I get that your expectations of a hashmap's behaviour was set by some programming language $FOO, and that it is reasonable to expect that someone who learned on $FOO has the expectation that a hashmap has a specific behaviour. But, that being said, after you learn that a hashmap is a concept independent of any programming language, and after you learned that that concept does not guarantee the behaviour you expect, it's signficantly easier to change your expectations for hashmap behaviour than to change the definition of the concept's guarantees.