Meh.
var colours = coordinates.stream().map(this::computeColour).collect(toList());
var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList());
Re:Why I Prefer Functional Programming
by przemo_li on Sunday November 01, 2020 @06:17PM
(#24963410)
You have just started that Java isn't as good but since it isn't, it shouldn't be judged so hardly and thus concluded that Java is as good as any (when using softer requirements just for Java)
I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method
Re:Why I Prefer Functional Programming
by AnimalMuppet on Monday November 02, 2020 @02:33PM
(#24972101)
Java's type safety in general is less than Haskell's. That's a separate topic from ease of parallelization in Java and Haskell.
Ray-tracing is absolutely trivial to parallelize, because every pixel is computed independently of all others. That would even be trivial to parallelize in C, and that's saying a lot!
Re:Why I Prefer Functional Programming
by CJefferson on Saturday October 31, 2020 @07:13PM
(#24956002)
I think this reasoning goes the other way (as I understand), Rust can express threadsafe mutability, as you can only have one mutable reference to any object, so if I can mutate, I know I have the only reference.
> let colors = fmap computeColor coordinates
to
> let colors = fmap computeColor coordinates `using` parListChunk 32 rseq
So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon comes pretty close but you can encode some properties about your computation in the Haskell type system that Rust does not yet support and so the safety of some computations can be statically proven in Haskell but not in Rust.