3 ms·

A problem with this is that Go code that uses native maps is non-deterministic, and is very annoying to make deterministic-ish when reproducing results is impor

A problem with this is that Go code that uses native maps is non-deterministic, and is very annoying to make deterministic-ish when reproducing results is important.

gjs278 5y ago
it’s not that hard and it makes sure your code isn’t relying on a magic order that can be screwed up by race conditions or some change to the map along the way. it’s a good idea to key it if order matters.
brundolf 5y ago
Hmm, seems like it should be a compiler option
- baq 5y ago
  this is about as against the go philosophy as it gets. 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.
- nicoburns 5y ago
  Rust simply has two types (HashMap and BtreeMap). And you can pick whichever you prefer.
pjmlp 5y ago
If that is required there are other data structures to pick from. This kind of behaviour should be visible on the application design and not depend on implementation details.
- masklinn 5y ago
  > If that is required there are other data structures to pick from. 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).
  - pjmlp 5y ago
    No different than using C, pre-C++98, Pascal, BASIC, Java pre-1.5. 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?
randomswede 5y ago
"is non-deterministic, when you use a plain range to iterate over such a map". 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.

A problem with this is that Go code that uses native maps is non-deterministic, and is very annoying to make deterministic-ish when reproducing results is important.

gjs278 5y ago

it’s not that hard and it makes sure your code isn’t relying on a magic order that can be screwed up by race conditions or some change to the map along the way. it’s a good idea to key it if order matters.

brundolf 5y ago

Hmm, seems like it should be a compiler option

baq 5y ago
this is about as against the go philosophy as it gets. 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.
nicoburns 5y ago
Rust simply has two types (HashMap and BtreeMap). And you can pick whichever you prefer.

pjmlp 5y ago

If that is required there are other data structures to pick from. This kind of behaviour should be visible on the application design and not depend on implementation details.

masklinn 5y ago
> If that is required there are other data structures to pick from. 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).
- pjmlp 5y ago
  No different than using C, pre-C++98, Pascal, BASIC, Java pre-1.5. 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?

randomswede 5y ago

"is non-deterministic, when you use a plain range to iterate over such a map". 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.