Hacker News Reader

There's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.

View on HN

The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).

Gotcha! So will Rust then auto-parallelize these "pure" closures?

We'd like to have generic APIs in the future that will allow idiomatic automatic data parallelization. Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

(Note that Servo has been using this type system feature for a while now to prevent data races in our massively parallel CSS layout code.)

> Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

Arrg, you have me excited now!

I wouldn't put my hopes very high on this. They tried doing this kind of ubiquitous automatic parallelization in Haskell but they ran into parallelization overhead issues because its very hard to have the computer figure out the correct parallelization granularity all by itself.

Having just started reading the Rust guides, I'm curious: can the closure type actually ensure it doesn't mutate any externally visible data, or does that only apply to memory? Can declare that a closure doesn't (or shouldn't be allowed to) write to disk or hit a database?

Reply on news.ycombinator.com