> The parent's point is that this is still within the guarantees hashmap (the abstract data structure) gives about order: none. This is not the point from the

> The parent's point is that this is still within the guarantees hashmap (the abstract data structure) gives about order: none. This is not the point from the parent point, at least nothing else in the text suggests so. > All the rest are details that are based on your particular conditions, which are very very very specific: They're not "very very specific", they're based on my experience in other programming languages. And when I say this, I am not talking about Python (that has ordered maps by default), but languages like Ruby or Java. > That's an implementation detail that shouldn't concern the user though. Go just goes out of the way to instill this, whereas other languages/libs do not. I think this thread is going anywhere, again, I am not saying Go or any other hash map implementation that does the same is wrong here. It is just that it is uncommon, that I had "one case in the past that if Go didn't randomise I wouldn't need to write extra code" (and I didn't say this case was common either), and that I would like ordered maps in the stdlib not just because of this particular case but because they are a really versatile (and would help in this case, but I never said it was the only case either where ordered maps matter). Keep in mind that I wrote this post on a sleepless night and didn't give much thought. My argument was never "this is the reason why we should have ordered maps in Go", it was mostly "I had this issue once, I think ordered maps are cool and if Go had them I wouldn't had this issue". I am still surprised how much (good) discussion this post ended up generating considering how little thought I gave at this post.