This Rayon issue has a good discussion of rayon vs spice/chili.
https://github.com/rayon-rs/rayon/issues/1235
In Beyond OpenMP in C++ and Rust: Taskflow, Rayon, Fork Unionrayon-rs
rayon
Rust2017–2025
rayon-rs / rayon
rayon
Rayon: A data parallelism library for Rust
25Distinct people
27Mentions
0Explicit recommenders
13.5KGitHub stars
What to know before exploring
What it is
Rayon: A data parallelism library for Rust
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2017-12-04 21:20:13 UTC to 2025-09-29 00:51:58 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Rayon
Rayon is a data-parallelism library for Rust. It is extremely
lightweight and makes it easy to convert a sequential computation into
a parallel one. It also guarantees data-race freedom. (You may also
enjoy this blog post about Rayon, which gives more background
and details about how it works, or this video, from the Rust
Belt Rust conference.) Rayon is
available on crates.io, and
API documentation is available on docs.rs.
Parallel iterators and more
Rayon makes it drop-dead simple to convert sequential iterators into
parallel ones: usually, you just change your foo.iter() call into
foo.par_iter(), and Rayon does the rest:
use rayon::prelude::*;
fn sum_of_squares(input: &[i32]) -> i32 {
input.par_iter() // <-- just change that!
.map(|&i| i * i)
.sum()
}
Parallel iterators take care of deciding how to divide your data
into tasks; it will dynamically adapt for maximum performance. If you
need more flexibility than that, Rayon also offers the join and
scope functions, which let you create parallel tasks on your own.
For even more control, you can create custom thread pools rather than
using Rayon's default, global thread pool.
No data races
You may have heard that parallel execution can produce all kinds of
crazy bugs. Well, rest easy. Rayon's APIs all guarantee data-race
freedom, which generally rules out most parallel bugs (though not
all). In other words, if your code compiles, it typically does the
same thing it did before.
For the most part, parallel iterators in particular are guaranteed to
produce the same results as their sequential counterparts. One caveat:
If your iterator has side effects (for example, sending methods to
other threads through a Rust channel or writing to disk), those side
effects may occur in a different order. Note also that, in some cases,
parallel iterators offer alternative versions of the sequential
iterator methods that can have higher performance.
Using Rayon
Rayon is available on crates.io. The
recommended way to use it is to add a line into your Cargo.toml such
as:
[dependencies]
rayon = "1.12"
To use the parallel iterator APIs, a number of traits have to be in
scope. The easiest way to bring those things into scope is to use the
Rayon prelude. In
each module where you would like to use the parallel iterator APIs,
just add:
use rayon::prelude::*;
Rayon currently requires rustc 1.85.0 or greater.
Usage with WebAssembly
By default, when building to WebAssembly, Rayon will treat it as any
other platform without multithreading support and will fall back to
sequential iteration. This allows existing code to compile and run
successfully with no changes necessary, but it will run slower as it
will only use a single CPU core.
You can build Rayon-based projects with proper multithreading support
for the Web, but you'll need an adapter and some project configuration
to account for differences between WebAssembly threads and threads on
the other platforms.
Check out the
wasm-bindgen-rayon
docs for more details.
Contribution
Rayon is an open source project! If you'd like to contribute to Rayon,
check out
the list of "help wanted" issues.
These are all (or should be) issues that are suitable for getting
started, and they generally include a detailed set of instructions for
what to do. Please ask questions if anything is unclear! Also, check
out the
Guide to Development
page on the wiki. Note that all code submitted in PRs to Rayon is
assumed to
be licensed under Rayon's dual MIT/Apache 2.0 licensing.
Quick demo
To see Rayon in action, check out the rayon-demo directory, which
includes a number of demos of code using Rayon. For example, run this
command to get a visualization of an N-body simulation. To see the
effect of using Rayon, press s to run sequentially and p to run in
parallel.
> cd rayon-demo
> cargo run --release -- nbody visualize
For more information on demos, try:
> cd rayon-demo
> cargo run --release -- --help
Other questions?
See the Rayon FAQ.
License
Rayon is distributed under the terms of both the MIT license and the
Apache License (Version 2.0). See LICENSE-APACHE and
LICENSE-MIT for details. Opening a pull request is
assumed to signal agreement with these licensing terms.
Read the full README on GitHubWhat Hacker News says
27 sourcesRayon: Data-race free parallelization of sequential computations in Rust
2 points · Open discussionRayon is a data-parallelism library for Rust
2 points · Open discussionOne of the others understated pros of rewriting some parts in Rust, it's that you can parallelize easily with Rayon[0]
[0] -- https://github.com/rayon-rs/rayon
In Making Python faster with Rust> He spoke of the potential for functional languages to provide a significant, intrinsic advantage when it comes to parallel computing.
> (...)
> If that were true, you'd expect that the many existing functional programming languages would have already satisfied this need. But in my opinion, they haven't
Well there is https://futhark-lang.org/ - it runs on the GPU, and is awesome.
On the CPU side, I think that Rust plus https://github.com/rayon-rs/rayon was a huge breakthrough on writing parallel programs using both functional and imperative programming, and future languages should learn from its successes. The ownership system & the borrow checker, plus other type-level features like the Send and Sync traits, were essential to enable sharing read-only data between threads without synchronization, or sharing read-write data with synchroni
Read the rest
zation, all checked at compile time for data races (which is a huge problem to solve, and is something that neither Go nor Java protects against at compile time)
Indeed Futhark shares a key feature with Rust: it uses uniqueness types to enable in-place updates, which is kind like a limited form of Rust ownership: if you are the sole user of some memory, you can update it and other code will be none the wiser. This kind of thing is very important to build functional programs that are performant in practice.
Not GP but I think the fundamental idea is to think about "who calls who" and have pure functions be called/scheduled by a stateful coordination mechanism.
Usually queues/channels/event loops are involved at the top level especially if you're doing async IO. If you're doing parallel computation then you'd probably use fan-in/fan-out/waitgroup logic at the top that calls into pure functions. The general point is "only this piece of code worries about coordinating state".
For async IO think Go's concurrency primitives, Clojure's core.async or Erlang/Elixir as examples of coordinating state through messages.
For parallelism specifically look at this pretty cool rust crate:
https://lib.rs/crates/rayon
Specifically at the discussion in the FAQ to get a sense of why it's useful to push mutability to the top level:
https://github.com/rayon-rs/ra
Read the rest
yon/blob/master/FAQ.md
As a counterpoint I'd like to link to a discussion about FP where Martin Thompson wrote:
https://groups.google.com/g/mechanical-sympathy/c/gSkbc3grzN...
> Most FP persistent data structures take the form of a tree and perform a path copy from leaf to root for the change, reusing as much of the tree as possible. What this results in is a single contention point at the root of the tree for CAS operations. Now expand this view to a larger domain model of many entities, e.g. Customers, Orders, Products, etc., all interrelated and that model needs one or more entry points. Each of these entry points become a contention hotspot as the model is mutated. Also with trees and linked lists being the underlying data structures, performance is limited due to indirection causing cache misses.
So really it matters a lot what you're doing. FP is not a panacea for concurrency and parallelism. As an application programmer that does mostly IO and very little heavy calculation etc. it's for example great.
If you don't know Rust, but know Python, you can install Python libraries written in Rust with pip. Like, pip install polars or pip install robyn. In this case you follow the two bottom links. But then you don't write your own libraries and stuff so.. I guess that's not what you want.
If creating your own Python libraries in Rust is what you want, you would check out the first link I sent only, the one for pyo3.
But, if you want to learn Rust, you probably wouldn't start out with pyo3. You first install Rust with https://rustup.rs/ and then check out the official book, and the book rust by example, that you can find here https://www.rust-lang.org/learn - and maybe write some code on the Rust playground https://play.rust-lang.org/ - then, you use pyo3 to build Python libraries in Rust, and then use maturin https://www.maturin.rs/ to build
Read the rest
and publish them to Pypi.
But if you still prefer to begin with Rust by writing Python libraries (it's a valid strategy if you are very comfortable with working with multiple stacks), the Maturin link has a tutorial that setups a program that is half written in python, half written in Rust, https://www.maturin.rs/tutorial.html (well the pyo3 link I sent also has one too. You should refer to the documentation of both, because you will use the two together)
After learning Rust and building some stuff with pyo3, the next step is looking for libraries that you could leverage to make Python programs ultra fast. Here https://github.com/rayon-rs/rayon is an obvious choice, see some examples from the Rust cookbook https://rust-lang-nursery.github.io/rust-cookbook/concurrenc... - when you create a parallel iterator, it will distribute the processing to many threads (by default, one per core). The rust cookbook, by the way, is a nice reference to see some of the most used crates (Rust libraries) in the Rust ecosystem.
If you are doing async stuff in Python, you probably need to look up https://github.com/awestlake87/pyo3-asyncio and https://tokio.rs/ - that's two libraries that Robyn uses (see Robyn dependencies here https://github.com/sansyrox/robyn/blob/main/Cargo.toml)
Anyway there are some posts about pyo3 on the web, like this blog post https://boring-guy.sh/posts/river-rust/ (note: it uses an outdated version of pyo3, and doesn't seem to use maturin which is a newer tool). This post was written by the developers of https://github.com/online-ml/river - another Python library written in Rust
Not sure if there's anything in the standard library, but I recall this as the definitive library for data parallelism in Rust: https://github.com/rayon-rs/rayon
In Someone is pretending to be me> If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset?
I suspect a garbage collector would be pretty nice. However, I can't just list the features I want and get a language (unless I make it myself, which would take a lot of time). Currently, my imaginary perfect language would actually have a garbage collector, would be pretty similar to Standard ML, but would be more focused on arrays than lists, and would have value types --- in Standard ML I can't have a value array of records (structs in Rust/C++ parlance) --- they will be behind a pointer. And if I were to stick to the standard or make sure that my code compiles with other compilers than MLTon, then I can't even have a value arra
Read the rest
y of 64-bit words, although I can have a value array of 63-bit words. This one bit may seem insignificant, but for certain algorithms it's a big complication. Powers of 2 simplify a lot of algorithms (and are "faster" to be a bit loose with the language). There are other features I'd like, but already this short list makes for a currently-non-existent language. OCaml and Haskell have similar problems to Standard ML.
At the same time Rust has great support for arrays, is expression-oriented, has sum types. Value types are the default. It generally ticks a lot of boxes I care about. I can't just go and say "now give me all that but with a GC" and have it appear before me.
Also, arenas I use are linked to logical portions of my programs. They are not contrivances that I had to think long and hard about. They don't waste my time really. I've spent 0 time thinking about how they should be organized.
Now the part where a GC would be helpful is a bit of a more liberal use of closures, and eliminating code noise coming from lifetime annotations such as "for<'a>". But I can live with the current state of affairs, if I get all the other benefits.
> If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset?
If anything, Rust is an asset for large teams of devs. Even though you may sometimes argue that a handful of C/C++ devs can keep their whole project in their heads and not make mistakes (although I think that's a stretch), the moment you get a large C/C++ team, weird hard-to-debug bugs coming from memory- and thread-safety issues start to creep in. There are other high-level languages, but Rust is the one with a combination of performance competitive with C++ and large ecosystem of libraries you can use. Examples of Rust projects with a large number of contributors facilitated by the language taking the fear of intractable bugs away:
- <https://github.com/BurntSushi/ripgrep>
- <https://github.com/clap-rs/clap>
- <https://github.com/rayon-rs/rayon>
- <https://github.com/cloudflare/wrangler>
- <https://github.com/sharkdp/fd>
> On a single machine I can just replace an `.iter()` into a `.par_iter()` in my Rust programs and boom, I parallelized my workload across every core with only a single line change.
If you’re using Rayon for anything you expect to benefit from a lot of cores, my experiences have been very negative in the past. Rayon is often extremely inefficient once you allow it to use more than a handful of cores.[0]
If your unit of work is absolutely massive, you might not be as affected by Rayon’s scheduler, but it makes me sad that this issue still hasn’t been resolved. My comment on that thread (documenting just one instance where I ran into this issue) was almost 4 years ago! And the issue itself is almost a year older than that. Sure, I could try to contribute a general solution, but it’s just easier to stop using Rayon.
I no longer consider Rayo
Read the rest
n to be an advantage for Rust. There are plenty of good ways to wire up a parallel work pool, but they do require more than a one line change.
[0]: https://github.com/rayon-rs/rayon/issues/394
Rust is picking up momentum with industrial use but is overall still pretty uncommon. rayon (https://github.com/rayon-rs/rayon) makes it easy to use all your CPU cores. for simple cases, it can be literally a one line change to turn a single-threaded loop into a parallel one.
In Ask HN: Why are you programming your hobby projects in a niche language?I'm looking forward to something like the brilliant rayon parallel operations library https://github.com/rayon-rs/rayon
We won't get data race free guarantees but if built into pandas or Vaex we can have a near transparent API.
It'll really open things up for those apps running on 32 core machines. They're out there, I deploy these things frequently (Plotly Dash framework for large Enterprise customers).
In Python stands to lose its GIL, and gain a lot of speedYou make it sound like Rust doesn’t support background CPU computation. Rust has always had threads (https://doc.rust-lang.org/book/ch16-01-threads.html), along with incredibly powerful libraries like Rayon (https://github.com/rayon-rs/rayon) to take advantage of them.
async/await wasn’t specifically targeted for that use case because it didn’t need to be. But you can use threads with async, if you want, using a multi-threaded scheduler like Tokio with the rt-multi-thread feature flag (https://docs.rs/tokio/1.7.0/tokio/runtime/index.html#multi-t...).
In Six ways to make async Rust easierRust's Rayon library is pretty good for these use-cases https://github.com/rayon-rs/rayon
use rayon::prelude::*;
fn sum_of_squares(input: &[i32]) -> i32 {
input.par_iter() // <-- just change that!
.map(|&i| i * i)
.sum()
}
In A 1000-processor chip powered by an AA battery (2016)Showing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.