Basically, Rayon makes data parallelism really easy in a way that few if any other languages do. I’d love to have an equivalent in Python or Node, but it’s just not possible to achieve such a thing in most languages—even if you ignore the thread safety aspect.

Parallelism hasn’t seen a great deal of use until it’s urgently needed, because it’s hard to get right in most environments, and you normally need to substantially refactor code to make it happen. My hope is that with the likes of Rayon, parallelism can be a much more natural thing that people that care even a little about performance will just do, because it’s so easy to do.

https://crates.io/crates/rayon

This is the main reason why, initially, Windows Store APIs were all async.

Microsoft learned that when developers can choose between both models, by default most chose synch models.

Syntax-wise, there's OpenMP which can turn a for-loop into a parallelized for-loop (independently scheduled iterations) with just some syntactic sugar on top of the loop.

OpenMP has support for at least C++ and Fortran, and is not hard to use.

I wonder how Rayon compares to OpenMP.

And in .NET https://docs.microsoft.com/en-us/dotnet/api/system.threading...

And in Java https://blog.oio.de/2016/01/22/parallel-stream-processing-in...

Rayon is notable because Rust is a native-compiled, no-GC language.

https://github.com/actix/actix

Parallelism is complicated though, and easy parallelism pretty much requires a functional style. Things like Haskell's Accelerate library (https://www.stackage.org/package/accelerate) seem the ideal way forward to me.

Apples to oranges comparison of course, since Rayon isn't [planned to become?] part of the Rust standard library.

[1] http://www.bfilipek.com/2017/08/cpp17-details-parallel.html#...

Go's implementation of these things is nice, neat, and all included out of the box though which is nice.

In general you can make parallelism easy, or efficient, rarely both, at least not in a way that can solve problems generally.

edit: I should add Go does also come with a data-race detection tool which can be very useful. Not sure any other language includes that out of the box!

> Not sure any other language includes that out of the box!

Rust's compiler does it by default, at compile time. ;-) Go's race detector is never wrong, but it may omit things. On the other hand, Rust's compiler is also neither wrong nor does it omit things, except under one circumstance: someone, somewhere, wrote `unsafe` code and committed a bug inside that block.

ThreadSanitizer is also a thing: https://clang.llvm.org/docs/ThreadSanitizer.html

Still not quite as tightly integrated as Go though.

(The person you're replying to is using the transparent internet argument tactic of trying to cast doubt upon genuine enthusiasm by implying some vague sinister motive, conveniently without bothering to articulate what that motive might even possibly be. Let's all recognize bad-faith arguments, downvote, and move along.)

I've experienced plenty of frustration, albeit outweighed by the massive benefits for my use case. And there are whole problem domains to which it's just not suited. I see these mentioned pretty frequently.

Rayon, the Rust library getting most of the discussion in this thread, is now 1.0: https://github.com/rayon-rs/rayon/blob/master/RELEASES.md .

Doesn't seem odd at all.

First, a lot of people commenting about Rust are enthusiastic recent adopters that haven't seen much of the language, including any real ugly sides yet.

Second, it's not entirely true, almost all Rust threads mention the steep learning curve, the slow compiler, and other issues such as the variadic generics (or lack thereof to be precise).

Third, we have seen the same "early adopter enthusiasts seeing it all rosy" circle for RoR, Go, Node, and Mongo, nothing out of the ordinary here.

You see the same with Rust, Elixir, VSCode, Elm, Purescript, ReasonML, etc.

It's not astroturfing, it's just a lot of beginners that are overly excited to proselytize their new discovery.