Other Essential Crates: itertools, rayon, LazyLock, uuid, indexmap, bytes, dashmap

24 min read

Quick Overview

Beyond the headline crates (serde, tokio, reqwest, clap), every working Rust project quickly accumulates a second tier of utilities that fill gaps a Node developer never thinks about — because in JavaScript they are either built into the language or live in one-line npm packages. This page covers seven of those workhorses: itertools (lodash-style iterator adapters), rayon (one-line data parallelism with no Worker boilerplate), once_cell/LazyLock (lazy global initialization), uuid (id generation), indexmap (a map that remembers insertion order, like a JS Map), bytes (cheap, refcounted byte buffers for network code), and dashmap (a concurrent HashMap you can share across threads). Knowing these saves you from reinventing them or reaching for unsafe.

Note: This page is the grab-bag of general-purpose utilities. The big, topic-specific crates live in their own pages: see popular-crates.md for the overview, async-runtimes.md for Tokio, http-clients.md for reqwest, date-time.md for chrono, regex.md for the regex crate, and parsing.md for nom/pest.

TypeScript/JavaScript Example

In Node, most of what this page covers is either a language built-in or a tiny dependency. Here is the everyday toolbox a TypeScript developer reaches for:

1
// The Node equivalents of everything on this page.
2
import { randomUUID } from "node:crypto";   // built-in UUID v4
3
import { groupBy, uniq, zip } from "lodash"; // iterator helpers
4
import { Worker } from "node:worker_threads"; // parallelism (heavy boilerplate)
5

6
// 1. Iterator helpers — lodash fills the gaps in Array.prototype.
7
const orders = [
8
  { customer: "alice", amount: 30 },
9
  { customer: "bob", amount: 10 },
10
  { customer: "alice", amount: 12 },
11
];
12
const byCustomer = groupBy(orders, (o) => o.customer);
13
// { alice: [ {..30}, {..12} ], bob: [ {..10} ] }
14

15
// 2. A lazily-initialized singleton (computed once, on first use).
16
let _config: Map<string, number> | undefined;
17
function settings(): Map<string, number> {
18
  if (!_config) {
19
    _config = new Map([["retries", 3], ["timeout", 30]]);
20
  }
21
  return _config;
22
}
23

24
// 3. UUIDs.
25
const id = randomUUID(); // "67e55044-10b1-426f-9247-bb680e5fe0c8"
26

27
// 4. A Map keeps insertion order; a plain object mostly does too.
28
const ordered = new Map<string, number>();
29
ordered.set("zulu", 1);
30
ordered.set("alpha", 2);
31
console.log([...ordered.keys()]); // ['zulu', 'alpha'] — insertion order
32

33
// 5. Concurrency on shared state is *not* a problem in Node:
34
//    one thread, one event loop, so a plain object is "thread-safe".
35
const counts: Record<string, number> = {};
36
counts["hits"] = (counts["hits"] ?? 0) + 1;

Three things about this code shape what Rust does differently:

Parallelism is exotic in Node. worker_threads means serializing data across a thread boundary; almost nobody reaches for it casually. Rust makes CPU parallelism a one-line change.
Shared mutable state is “free” in Node because there is only one thread. In Rust, sharing a HashMap across threads does not compile — you need a concurrency-aware type like dashmap.
Map remembers insertion order; Object mostly does. Rust’s default HashMap is deliberately unordered (and randomized), so when you need Map-like ordering you reach for indexmap.

Rust Equivalent

The same five concerns, the idiomatic Rust way. First the dependencies:

1
# Cargo.toml — add these with `cargo add` so versions resolve to current stable.
2
[dependencies]
3
itertools = "0.14"
4
rayon = "1.12"
5
uuid = { version = "1.23", features = ["v4", "v7"] }
6
indexmap = "2.14"
7
bytes = "1.11"
8
dashmap = "6.2"
9
# once_cell is optional now — std's LazyLock (stable since Rust 1.80) covers most uses.

1
use itertools::Itertools;
2
use rayon::prelude::*;
3
use std::collections::HashMap;
4
use std::sync::LazyLock;
5
use indexmap::IndexMap;
6
use dashmap::DashMap;
7
use uuid::Uuid;
8

9
// 2. A lazily-initialized global, computed once on first access. No `if (!_x)` dance.
10
static SETTINGS: LazyLock<HashMap<&'static str, i32>> = LazyLock::new(|| {
11
    HashMap::from([("retries", 3), ("timeout", 30)])
12
});
13

14
fn main() {
15
    // 1. Iterator helpers — itertools is lodash for Rust's iterators.
16
    let words = ["apple", "banana", "apple", "cherry", "banana", "apple"];
17
    let counts = words.iter().counts(); // HashMap<&&str, usize>
18
    let mut counts_sorted: Vec<_> = counts.into_iter().collect();
19
    counts_sorted.sort();
20
    println!("counts: {counts_sorted:?}");
21

22
    // 3. Parallelism — change `.iter()` to `.par_iter()` and rayon does the rest.
23
    let total: u64 = (1..=1_000_000u64).into_par_iter().filter(|n| n % 3 == 0).sum();
24
    println!("rayon sum: {total}");
25

26
    // 2. The global is initialized lazily, on first read.
27
    println!("retries: {}", SETTINGS["retries"]);
28

29
    // 4. UUIDs.
30
    let id = Uuid::new_v4();
31
    println!("uuid v4 has {} chars", id.to_string().len());
32

33
    // 5. A map that preserves insertion order, like a JS Map.
34
    let mut ordered: IndexMap<&str, i32> = IndexMap::new();
35
    ordered.insert("zulu", 1);
36
    ordered.insert("alpha", 2);
37
    println!("indexmap keys: {:?}", ordered.keys().collect::<Vec<_>>());
38

39
    // 6. A concurrent map you can share across threads without a Mutex<HashMap>.
40
    let hits: DashMap<&str, i32> = DashMap::new();
41
    *hits.entry("hits").or_insert(0) += 1;
42
    println!("dashmap hits: {}", *hits.get("hits").unwrap());
43
}

Running it prints:

1
counts: [("apple", 3), ("banana", 2), ("cherry", 1)]
2
rayon sum: 166666833333
3
retries: 3
4
uuid v4 has 36 chars
5
indexmap keys: ["zulu", "alpha"]
6
dashmap hits: 1

Detailed Explanation

itertools — lodash for iterators

Rust’s standard Iterator trait is already richer than Array.prototype (map, filter, take, skip, flat_map, zip, fold…), but it deliberately omits anything that would need allocation or buffering. itertools is the crate that adds them. You bring its methods into scope with one use itertools::Itertools; and they appear on every iterator.

A few you will reach for constantly:

1
use itertools::Itertools;
2

3
fn main() {
4
    // join: like Array.prototype.join, but on any iterator of Display values.
5
    let joined = ["a", "b", "c"].iter().join(", ");
6
    println!("{joined}"); // a, b, c
7

8
    // counts: a frequency map in one call (lodash's countBy).
9
    let counts = ["x", "y", "x", "x"].iter().counts();
10
    println!("{:?}", counts.get(&&"x")); // Some(3)
11

12
    // cartesian_product: every pair, no nested loops.
13
    let pairs: Vec<(i32, char)> =
14
        [1, 2].iter().copied().cartesian_product(['x', 'y']).collect();
15
    println!("{pairs:?}"); // [(1, 'x'), (1, 'y'), (2, 'x'), (2, 'y')]
16

17
    // sorted + dedup: sort then remove consecutive duplicates.
18
    let unique: Vec<i32> = [3, 1, 2, 3, 1].iter().copied().sorted().dedup().collect();
19
    println!("{unique:?}"); // [1, 2, 3]
20

21
    // chunk_by: group *consecutive* runs by a key (like a streaming groupBy).
22
    let runs: Vec<(bool, Vec<i32>)> = [1, 2, 4, 3, 5, 6]
23
        .iter()
24
        .copied()
25
        .chunk_by(|n| n % 2 == 0)
26
        .into_iter()
27
        .map(|(k, g)| (k, g.collect()))
28
        .collect();
29
    println!("{runs:?}"); // [(false, [1]), (true, [2, 4]), (false, [3, 5]), (true, [6])]
30
}

This prints:

1
a, b, c
2
Some(3)
3
[(1, 'x'), (1, 'y'), (2, 'x'), (2, 'y')]
4
[1, 2, 3]
5
[(false, [1]), (true, [2, 4]), (false, [3, 5]), (true, [6])]

Warning: chunk_by groups consecutive equal keys, exactly like Unix uniq and unlike lodash’s groupBy, which gathers all matching items regardless of position. To get lodash semantics, .sorted_by(...) first (so equal keys are adjacent), then chunk_by. We do exactly that in the Real-World Example below.

itertools also adds izip!, which zips three or more iterators at once — std’s zip only takes two:

1
use itertools::izip;
2

3
fn main() {
4
    let names = ["a", "b", "c"];
5
    let ages = [30, 25, 40];
6
    let cities = ["NYC", "LA", "SF"];
7
    for (n, age, city) in izip!(names, ages, cities) {
8
        println!("{n} {age} {city}");
9
    }
10
}

1
a 30 NYC
2
b 25 LA
3
c 40 SF

rayon — data parallelism for the price of one method call

This is the crate with the best effort-to-reward ratio in the ecosystem. To parallelize a sequential iterator chain, you change .iter() to .par_iter() (or .into_iter() to .into_par_iter()) and add use rayon::prelude::*;. rayon spreads the work across a thread pool sized to your CPU cores using work-stealing, and the compiler still enforces that your closure does not race on shared data.

1
use rayon::prelude::*;
2

3
fn main() {
4
    // Sequential: .iter()  →  Parallel: .par_iter()
5
    let total: u64 = (1..=1_000_000u64)
6
        .into_par_iter()
7
        .filter(|n| n % 3 == 0)
8
        .sum();
9
    println!("sum of multiples of 3: {total}");
10

11
    // par_sort sorts a slice across all cores in place.
12
    let mut data: Vec<i64> = (0..10).rev().collect();
13
    data.par_sort();
14
    println!("{data:?}");
15

16
    // reduce needs an identity value and an *associative* combining op.
17
    let factorial: u64 = (1..=10u64).into_par_iter().reduce(|| 1, |a, b| a * b);
18
    println!("10! = {factorial}");
19
}

1
sum of multiples of 3: 166666833333
2
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
3
10! = 3628800

Compare this to Node, where the same CPU-bound work would require spawning Worker threads, serializing inputs into them with postMessage, and reassembling the results — dozens of lines for what rayon expresses in one. The reason Rust can do this safely is the same Send/Sync machinery that powers the rest of the language: if your closure tried to mutate captured state without synchronization, it would not compile. This is the “fearless concurrency” promise made concrete. (rayon is for CPU-bound parallelism; for I/O-bound concurrency you want async and Tokio — see async-runtimes.md.)

once_cell / LazyLock — lazy globals done right

A global that is expensive to build (a compiled regex, a config table, a connection registry) should be initialized once, on first use, and then shared. In JavaScript you write the if (!_x) _x = ... lazy-init pattern by hand. Rust gives you two tools:

std::sync::LazyLock — built into the standard library, stable since Rust 1.80. Prefer this in new code; it needs no dependency.
once_cell::sync::Lazy — the original crate that LazyLock was modeled on. You will still see it everywhere in existing code and crates that support older compilers, and its API is nearly identical.

1
use once_cell::sync::Lazy;
2
use std::sync::LazyLock;
3
use std::collections::HashMap;
4

5
// once_cell crate (pre-1.80 idiom, still extremely common in the wild).
6
static REGISTRY_OLD: Lazy<HashMap<&str, u32>> =
7
    Lazy::new(|| HashMap::from([("alpha", 1), ("beta", 2)]));
8

9
// std LazyLock (prefer this in new code — no dependency needed).
10
static REGISTRY_NEW: LazyLock<HashMap<&str, u32>> =
11
    LazyLock::new(|| HashMap::from([("alpha", 1), ("beta", 2)]));
12

13
fn main() {
14
    println!("once_cell: {}", REGISTRY_OLD["beta"]);
15
    println!("LazyLock:  {}", REGISTRY_NEW["beta"]);
16
}

1
once_cell: 2
2
LazyLock:  2

The closure runs exactly once, the first time the static is accessed, and the result is cached for the program’s lifetime. Both types are thread-safe: if two threads race to first-access, one wins the initialization and the other blocks until it completes. The migration is mechanical — once_cell::sync::Lazy becomes std::sync::LazyLock with the same closure.

Note: once_cell also offers OnceCell/Lazy for the non-thread-safe (unsync) case and a get_or_init API; std mirrors these as OnceCell/OnceLock. For a plain “initialize once, no closure stored” cell, std’s OnceLock is the analogue of once_cell::sync::OnceCell.

uuid — id generation

The uuid crate generates and parses UUIDs. You opt into the versions you need via Cargo features; the two you want today are v4 (random) and v7 (timestamp-ordered, the modern default for database keys because the ids sort by creation time, which is friendlier to B-tree indexes).

1
use uuid::Uuid;
2

3
fn main() {
4
    let random = Uuid::new_v4();   // fully random (like Node's randomUUID)
5
    let ordered = Uuid::now_v7();  // time-sortable; great for DB primary keys
6

7
    println!("v4: {random}");
8
    println!("v7 version number: {}", ordered.get_version_num());
9

10
    // Parse a UUID from a string (returns Result, no exceptions).
11
    let parsed = Uuid::parse_str("67e55044-10b1-426f-9247-bb680e5fe0c8").unwrap();
12
    println!("parsed: {parsed}");
13
}

A sample run (the random parts differ each time):

1
v4: 9f1d8c2a-...-...-...-............
2
v7 version number: 7
3
parsed: 67e55044-10b1-426f-9247-bb680e5fe0c8

Node’s built-in crypto.randomUUID() only gives you v4. If you want time-ordered ids in Node you need a third-party package; in Rust it is a one-feature flag away.

indexmap — a map that remembers insertion order

Rust’s standard HashMap is unordered, and its iteration order is even randomized per-run to discourage you from depending on it. That is the opposite of a JavaScript Map, which guarantees insertion order. When you need that guarantee — serializing config back out in a stable order, building an ordered cache, preserving the order of HTTP headers — reach for indexmap.

1
use indexmap::IndexMap;
2

3
fn main() {
4
    let mut map: IndexMap<&str, i32> = IndexMap::new();
5
    map.insert("zulu", 1);
6
    map.insert("alpha", 2);
7
    map.insert("mike", 3);
8

9
    // Iterates in insertion order, like a JS Map.
10
    println!("keys: {:?}", map.keys().collect::<Vec<_>>());
11

12
    // Bonus: positional access, which a HashMap cannot do.
13
    println!("first entry: {:?}", map.get_index(0));
14
}

1
keys: ["zulu", "alpha", "mike"]
2
first entry: Some(("zulu", 1))

Warning: IndexMap has two ways to remove an entry, and they are not interchangeable. swap_remove(key) is O(1) but moves the last element into the gap, breaking order. shift_remove(key) is O(n) but preserves order by sliding subsequent entries down. If you chose IndexMap for its ordering, you almost always want shift_remove. The default .remove() was deliberately removed from the API to force this choice:

1
use indexmap::IndexMap;
2

3
fn main() {
4
    let mut a: IndexMap<&str, i32> = ["a", "b", "c", "d"].iter().map(|&k| (k, 0)).collect();
5
    a.swap_remove("b");  // moves "d" into b's slot — order broken
6
    println!("swap_remove:  {:?}", a.keys().collect::<Vec<_>>());
7

8
    let mut b: IndexMap<&str, i32> = ["a", "b", "c", "d"].iter().map(|&k| (k, 0)).collect();
9
    b.shift_remove("b"); // shifts "c","d" down — order preserved
10
    println!("shift_remove: {:?}", b.keys().collect::<Vec<_>>());
11
}

1
swap_remove:  ["a", "d", "c"]
2
shift_remove: ["a", "c", "d"]

bytes — cheap, refcounted byte buffers

Network and protocol code constantly slices and shares byte buffers. Copying them every time is wasteful, and in Node you reach for Buffer.slice (which shares memory) or Buffer.subarray. The bytes crate is the Rust equivalent and the foundation that hyper, Tokio, and most of the HTTP stack are built on. Its key types are Bytes (immutable, cheaply cloneable) and BytesMut (a growable buffer you build up, then freeze() into Bytes).

The crucial property: cloning a Bytes is O(1) — it bumps a reference count and shares the underlying allocation rather than copying the data. Slicing is likewise O(1) and shares memory.

1
use bytes::{Bytes, BytesMut, Buf, BufMut};
2

3
fn main() {
4
    // Build up a buffer, then freeze it into an immutable Bytes.
5
    let mut buf = BytesMut::with_capacity(64);
6
    buf.put_u8(0xFF);          // write a length/version byte
7
    buf.put(&b"hello"[..]);    // write a payload
8
    let frozen: Bytes = buf.freeze();
9

10
    // clone() and slice() are O(1): they share the same allocation.
11
    let header = frozen.slice(0..1);
12
    let body = frozen.slice(1..);
13
    println!("header: {header:?}, body: {body:?}");
14

15
    // The Buf trait lets you consume bytes like a cursor (advances position).
16
    let mut reader = frozen.clone();
17
    let version = reader.get_u8();       // reads 1 byte, advances
18
    println!("version: {version:#X}, {} bytes left", reader.remaining());
19
}

1
header: b"\xff", body: b"hello"
2
version: 0xFF, 5 bytes left

put_u8/get_u8 come from the BufMut/Buf traits, which give you endian-aware, cursor-style reads and writes — exactly what you want when parsing a binary protocol. Unless you are writing networking or codec code you may never need bytes directly, but you will see Bytes in the signatures of hyper, reqwest, and Tokio, so it pays to recognize it.

dashmap — a concurrent HashMap

Here is a place where Rust forces work that Node never asks of you. In Node, a plain object is a concurrent map because there is only one thread; reads and writes can never interleave. In Rust, sharing a HashMap across threads does not compile — you would need to wrap it in Arc<Mutex<HashMap>>, which serializes all access through one lock, even reads of unrelated keys.

dashmap is a drop-in HashMap replacement that is safe to share and mutate from many threads at once. Internally it shards the map into many independently-locked segments, so two threads touching different keys rarely contend. Crucially, you can mutate it through a shared & reference (no outer Mutex needed), which is exactly what par_iter and threads require.

1
use dashmap::DashMap;
2
use std::sync::Arc;
3
use std::thread;
4

5
fn main() {
6
    // Share one map across threads. No Mutex<HashMap>, no &mut.
7
    let map: Arc<DashMap<&'static str, i32>> = Arc::new(DashMap::new());
8

9
    let handles: Vec<_> = (0..4)
10
        .map(|_| {
11
            let map = Arc::clone(&map);
12
            thread::spawn(move || {
13
                for _ in 0..1000 {
14
                    *map.entry("hits").or_insert(0) += 1;
15
                }
16
            })
17
        })
18
        .collect();
19

20
    for h in handles {
21
        h.join().unwrap();
22
    }
23

24
    // 4 threads × 1000 increments, no lost updates.
25
    println!("hits: {}", *map.get("hits").unwrap());
26
}

1
hits: 4000

Each entry().or_insert() is atomic with respect to that key, so the increments do not race even though four threads hammer the same entry. This is the structure you would use for a shared cache, a connection pool’s bookkeeping, or per-key counters in a server.

Key Differences

Concern	JavaScript / Node	Rust
Iterator helpers	`Array.prototype` + lodash	std `Iterator` + itertools
`groupBy`	lodash gathers all matches	itertools `chunk_by` groups consecutive; sort first for lodash semantics
CPU parallelism	`worker_threads` (heavy, serialize across boundary)	rayon: `.iter()` → `.par_iter()`, compiler-checked
Lazy singleton	hand-rolled `if (!_x)`	LazyLock (std, ≥1.80) or once_cell `Lazy`
UUID	`crypto.randomUUID()` (v4 only)	uuid with `v4`/`v7` features
Ordered map	`Map` keeps insertion order	default `HashMap` is unordered; use indexmap
Map removal order	always preserved	`swap_remove` (fast, reorders) vs `shift_remove` (ordered)
Shared byte buffers	`Buffer.slice` shares memory	bytes `Bytes` — O(1) clone/slice, refcounted
Concurrent map	plain object (single thread)	dashmap — sharded locks, mutate via `&`

The deepest conceptual gap is the last two rows. In Node, concurrency safety is a non-issue because of the single-threaded event loop, so a plain object doubles as a “thread-safe” map and you never think about it. Rust does not have that luxury — it is genuinely multi-threaded when you ask it to be — so it surfaces the choice in the type system. The upside is that data races are caught at compile time, not in production at 3 a.m. The trade is that “just share a map” becomes “pick dashmap (or Arc<Mutex<HashMap>>)” — a deliberate, visible decision.

Common Pitfalls

Forgetting to bring the itertools trait into scope

itertools adds its methods through the Itertools extension trait. If you call .join() or .counts() without importing it, the method simply does not exist:

1
fn main() {
2
    // does not compile (error[E0599]: no method named `join`)
3
    let joined = ["a", "b", "c"].iter().join(", ");
4
    println!("{joined}");
5
}

The real compiler error is:

1
error[E0599]: no method named `join` found for struct `std::slice::Iter` in the current scope
2
 --> src/main.rs:2:41
3
  |
4
2 |     let joined = ["a", "b", "c"].iter().join(", ");
5
  |                  ---------------        ^^^^ method not found in `std::slice::Iter<'_, &str>`
6
  |                  |
7
  |                  method `join` is available on `&[&str]`

The fix is one line at the top: use itertools::Itertools;. (This trait-import requirement is the same pattern as rayon’s use rayon::prelude::*; — extension traits must be in scope for their methods to appear.)

Deadlocking dashmap by holding two guards on the same key

dashmap’s get returns a read guard that holds a lock on that key’s shard. If you then try to take a write guard for the same key while the read guard is still alive, the second call blocks forever — a classic self-deadlock:

1
use dashmap::DashMap;
2

3
fn main() {
4
    let map: DashMap<&str, i32> = DashMap::new();
5
    map.insert("a", 1);
6

7
    // This COMPILES but DEADLOCKS at runtime:
8
    let one = map.get("a").unwrap();          // read guard, still alive...
9
    let mut two = map.get_mut("a").unwrap();  // ...so this write guard blocks forever
10
    *two += *one;
11
    println!("never reached");
12
}

The borrow checker cannot catch this because both guards borrow the DashMap immutably (that is the whole point of mutating through &) — the lock is a runtime construct. The fix is to not hold overlapping guards: read the value into a plain local and drop the guard before taking the write guard, or use entry(...).and_modify(...) / alter(...) which take a single guard internally. The same hazard exists with iter() while inserting.

Expecting `HashMap` to preserve insertion order

Coming from JavaScript’s Map, it is tempting to assume any map keeps order. Rust’s HashMap does not — and its iteration order is randomized per process, so a test that happens to pass locally can fail in CI:

1
use std::collections::HashMap;
2

3
fn main() {
4
    let mut m = HashMap::new();
5
    m.insert("zulu", 1);
6
    m.insert("alpha", 2);
7
    m.insert("mike", 3);
8
    // Order is unspecified and may differ every run — do NOT rely on it.
9
    println!("{:?}", m.keys().collect::<Vec<_>>());
10
}

If you need ordering, use IndexMap (insertion order) or BTreeMap (sorted order — see ../07-collections/05_btreemap-btreeset.md). Never assert on HashMap iteration order in a test.

Reaching for rayon on I/O-bound work

rayon parallelizes CPU work across a thread pool. If your loop is dominated by network or disk I/O (awaiting HTTP responses, reading files), rayon will tie up its threads blocking on syscalls and you will not get the concurrency you wanted. That is what async/Tokio is for. Rule of thumb: rayon for crunching numbers, Tokio for waiting on the network. Mixing them needs care — do not call blocking rayon work directly inside an async task without spawn_blocking.

Choosing the wrong `IndexMap` removal

As shown above, swap_remove silently reorders the map. If you picked IndexMap specifically to keep order and then call swap_remove, you have quietly defeated the purpose. Default to shift_remove unless you have measured that the O(n) shift matters and you do not care about order at that point.

Best Practices

Prefer std LazyLock over the once_cell crate in new code. It is stable (since Rust 1.80), needs no dependency, and has the same ergonomics. Keep once_cell only when you must support older compilers or need its unsync variants.
Parallelize last, measure first. rayon makes .par_iter() trivial, but the thread-pool coordination has overhead. For small inputs the sequential version is faster. Profile (see ../21-performance/README.md) before sprinkling par_ everywhere.
Use UUID v7 for database keys, v4 for opaque tokens. v7’s time-ordering keeps B-tree index inserts near the “right” of the tree, reducing page splits; v4’s full randomness is what you want when ordering would leak information.
Default to shift_remove on IndexMap unless you have a measured reason to trade order for speed.
Reach for dashmap only when you genuinely share a map across threads. Within a single thread, or behind one short-lived lock, a plain HashMap (or Arc<Mutex<HashMap>>) is simpler and the standard choice. dashmap shines under concurrent read/write contention.
Recognize bytes types rather than fight them. When a crate hands you Bytes, clone it freely (it is cheap) and slice it instead of copying. Only build BytesMut yourself when authoring a codec or protocol.
Keep use itertools::Itertools; and use rayon::prelude::*; at the top. Both crates work through extension traits that must be in scope; the imports are the price of admission.

Real-World Example

A concurrent word-frequency counter — the kind of thing you would build for log analysis or search indexing. It uses rayon to process documents in parallel, dashmap to accumulate counts safely across threads, and itertools to produce a sorted top-N report. This single function combines four of the crates on this page.

1
// cargo add rayon dashmap itertools
2
use dashmap::DashMap;
3
use rayon::prelude::*;
4
use itertools::Itertools;
5
use std::sync::Arc;
6

7
/// Count word frequencies across many documents in parallel,
8
/// then return them sorted by descending count (ties broken alphabetically).
9
fn word_frequencies(docs: &[&str]) -> Vec<(String, usize)> {
10
    let counts: Arc<DashMap<String, usize>> = Arc::new(DashMap::new());
11

12
    // Each document is processed on the rayon thread pool; all threads
13
    // write into the same DashMap concurrently and safely.
14
    docs.par_iter().for_each(|doc| {
15
        for word in doc.split_whitespace() {
16
            let key = word.to_lowercase();
17
            *counts.entry(key).or_insert(0) += 1;
18
        }
19
    });
20

21
    // Reclaim the map (we are the only owner now) and sort with itertools.
22
    Arc::try_unwrap(counts)
23
        .expect("all worker threads have finished")
24
        .into_iter()
25
        .sorted_by(|a, b| b.1.cmp(&a.1).then(a.0.cmp(&b.0)))
26
        .collect()
27
}
28

29
fn main() {
30
    let docs = [
31
        "the quick brown fox",
32
        "the lazy dog the fox",
33
        "quick quick brown the",
34
    ];
35

36
    for (word, count) in word_frequencies(&docs).iter().take(4) {
37
        println!("{word:>6}: {count}");
38
    }
39
}

Running it prints:

1
   the: 4
2
 quick: 3
3
 brown: 2
4
   fox: 2

The interesting part is what is not there: no Worker threads, no postMessage, no lock around the map, and no possibility of a lost update — yet four crates cooperate to do genuinely parallel work. par_iter() spreads the documents across cores, DashMap’s per-key atomic entry().or_insert() keeps the counts correct under contention, Arc::try_unwrap recovers sole ownership once the parallel section is done, and itertools’ sorted_by gives a stable, descending report.

Exercises

Exercise 1: Totals by customer with itertools

Difficulty: Beginner

Objective: Use itertools’ sorted_by + chunk_by to reproduce lodash groupBy semantics and aggregate within each group.

Instructions: Given a slice of Order { customer: String, amount: u32 }, write totals_by_customer that returns a Vec<(String, u32)> of each customer’s summed amount. Remember that chunk_by only groups consecutive keys, so you must sort by customer first.

Solution

1
// cargo add itertools
2
use itertools::Itertools;
3

4
#[derive(Debug)]
5
struct Order {
6
    customer: String,
7
    amount: u32,
8
}
9

10
fn totals_by_customer(orders: &[Order]) -> Vec<(String, u32)> {
11
    orders
12
        .iter()
13
        .sorted_by(|a, b| a.customer.cmp(&b.customer)) // make equal keys adjacent
14
        .chunk_by(|o| o.customer.clone())
15
        .into_iter()
16
        .map(|(customer, group)| (customer, group.map(|o| o.amount).sum()))
17
        .collect()
18
}
19

20
fn main() {
21
    let orders = vec![
22
        Order { customer: "alice".into(), amount: 30 },
23
        Order { customer: "bob".into(),   amount: 10 },
24
        Order { customer: "alice".into(), amount: 12 },
25
        Order { customer: "bob".into(),   amount: 5 },
26
        Order { customer: "carol".into(), amount: 100 },
27
    ];
28
    for (c, total) in totals_by_customer(&orders) {
29
        println!("{c}: {total}");
30
    }
31
}

Output:

1
alice: 42
2
bob: 15
3
carol: 100

sorted_by clusters each customer’s orders together so chunk_by can group them; without the sort, the two alice orders (separated by a bob) would land in two different chunks.

Exercise 2: Parallel id assignment

Difficulty: Intermediate

Objective: Use rayon and uuid together, and confirm the version of the generated ids.

Instructions: Write assign_ids(names: &[&str]) -> Vec<(Uuid, String)> that, in parallel, pairs each name with a fresh time-ordered UUID (v7) and uppercases the name. In main, verify that every id reports version number 7.

Solution

1
// cargo add rayon
2
// cargo add uuid --features v7
3
use rayon::prelude::*;
4
use uuid::Uuid;
5

6
fn assign_ids(names: &[&str]) -> Vec<(Uuid, String)> {
7
    names
8
        .par_iter()
9
        .map(|name| (Uuid::now_v7(), name.to_uppercase()))
10
        .collect()
11
}
12

13
fn main() {
14
    let names = ["ada", "linus", "grace", "alan"];
15
    let assigned = assign_ids(&names);
16

17
    println!("assigned {} ids", assigned.len());
18
    let all_v7 = assigned.iter().all(|(id, _)| id.get_version_num() == 7);
19
    println!("all v7: {all_v7}");
20
    for (_, name) in &assigned {
21
        println!("  {name}");
22
    }
23
}

Output:

1
assigned 4 ids
2
all v7: true
3
  ADA
4
  LINUS
5
  GRACE
6
  ALAN

par_iter().map(...).collect() runs the closures across the thread pool while collect reassembles the results in input order, so the names line up with their positions.

Exercise 3: A thread-safe LRU-ish hit counter

Difficulty: Advanced

Objective: Combine dashmap, LazyLock, and std::thread into a shared, concurrent counter behind a global.

Instructions: Declare a global static HITS: LazyLock<DashMap<String, u64>>. Write a function record(path: &str) that increments the counter for that path. Spawn several threads that each call record many times on a shared set of paths, then print the totals sorted by path. Confirm there are no lost updates.

Solution

1
// cargo add dashmap
2
use dashmap::DashMap;
3
use std::sync::LazyLock;
4
use std::thread;
5

6
// One global, lazily built, safely shared across all threads.
7
static HITS: LazyLock<DashMap<String, u64>> = LazyLock::new(DashMap::new);
8

9
fn record(path: &str) {
10
    // entry().or_insert() is atomic per key — no lost updates.
11
    *HITS.entry(path.to_string()).or_insert(0) += 1;
12
}
13

14
fn main() {
15
    let paths = ["/", "/about", "/contact"];
16

17
    let handles: Vec<_> = (0..8)
18
        .map(|_| {
19
            thread::spawn(move || {
20
                for _ in 0..1000 {
21
                    for p in paths {
22
                        record(p);
23
                    }
24
                }
25
            })
26
        })
27
        .collect();
28

29
    for h in handles {
30
        h.join().unwrap();
31
    }
32

33
    // 8 threads × 1000 iterations = 8000 hits per path.
34
    let mut totals: Vec<(String, u64)> =
35
        HITS.iter().map(|e| (e.key().clone(), *e.value())).collect();
36
    totals.sort();
37
    for (path, count) in totals {
38
        println!("{path}: {count}");
39
    }
40
}

Output:

1
/: 8000
2
/about: 8000
3
/contact: 8000

Because HITS is a LazyLock<DashMap>, every thread sees the same map (no Arc needed — a static lives for the whole program), and entry().or_insert() makes each increment atomic, so all 8000 hits per path are counted with no races. Swapping the DashMap for a plain HashMap here would not even compile, since a static HashMap cannot be mutated through a shared reference.

Other Essential Crates: itertools, rayon, LazyLock, uuid, indexmap, bytes, dashmap

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

itertools — lodash for iterators

rayon — data parallelism for the price of one method call

once_cell / LazyLock — lazy globals done right

uuid — id generation

indexmap — a map that remembers insertion order

bytes — cheap, refcounted byte buffers

dashmap — a concurrent HashMap

Key Differences

Common Pitfalls

Forgetting to bring the itertools trait into scope

Deadlocking dashmap by holding two guards on the same key

Expecting HashMap to preserve insertion order

Reaching for rayon on I/O-bound work

Choosing the wrong IndexMap removal

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Totals by customer with itertools

Exercise 2: Parallel id assignment

Exercise 3: A thread-safe LRU-ish hit counter

Expecting `HashMap` to preserve insertion order

Choosing the wrong `IndexMap` removal