[lukaslalinsky]

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

[derkha]

What would that abstraction look like? I really can't think of a more high-level abstraction of parallelism than a single method call saying "Please parallelize this sequential algorithm. But only when it makes sense."

[pcwalton]

How does not being able to write the high-level par_iter() abstraction make Golang more high-level?

[lukaslalinsky]

I didn't say Go is more high-level, I said Go doesn't allow you to do low-level things efficiently. Writing your own parallelism library requires good access to the language's execution model internals. Go doesn't give you that, because Go wants you to write application code, not library code. It's often frustrating, because sometimes you want to write a generic low-level library that will add no overhead to the code that uses is, but on the other hand it's very liberating, because you know what you have available and you instead focus on your application code.

[tatterdemalion]

It would be accurate to say that Go gives you neither low level control nor high level abstraction, whereas Rust gives you both.

[pcwalton]

None of the primitives Golang gives you allow you to achieve the same results that Rayon does. The Go work stealing system only works with goroutines, which are too expensive to spawn on every iteration of a tight loop.