It's an imperative language with side-effects, unordered mapping would break expectations and produce buggy code.
You can still achieve those speed ups, you just need to be explicit about the division (e.g., by creating a channel, launching goroutines and then collecting the results).
I'm not talking about what Go is; I'm more interested in what it might have been. There's nothing in the law that prevents mapping with side effects. If the side-effects don't require a particular order, why constrain them?
I'm not talking about what Go is; I'm more interested in what it might have been.
Well yes, but there are certain core concepts that define Go, and being imperative with side-effects is one of them. If we drop that, then we're no longer discussing Go but some hypothetical language.
There's nothing in the law that prevents mapping with side effects. If the side-effects don't require a particular order, why constrain them?
But they aren't constrained, they just aren't built-in. Go has loops, not maps, but if one wants to make a mapping function, the link I posted shows there's no constraint in having it execute out of order.
You can still achieve those speed ups, you just need to be explicit about the division (e.g., by creating a channel, launching goroutines and then collecting the results).
https://sites.google.com/site/gopatterns/concurrency/paralle...