►
Description
Materials for this talk are available at https://speakerdeck.com/nikomatsakis/rayon-rust-belt-rust
Rayon is a convenient library for adding parallelism into Rust programs. Rayon allows you to easily convert for loops using iterators to run in parallel, as well as recursive functions. Under the covers, Rayon uses work-stealing to dynamically balance your parallel processing, allowing it to scale gracefully to different numbers or processors and a diverse range of workloads. Best of all, thanks to Rust's ownership and borrowing sytem, using Rayon is guaranteed not to add data races to your programs. This talk will summarize how you can use Rayon in your own programs, as well as lifting the covers to show how Rayon itself is implemented.
http://www.rust-belt-rust.com/
A
A
A
The
idea
of
rayon
is
I
want
to
make
it
easy
for
you
to
add
parallelism
into
your
code
and
specifically
I
want
to
make
it
really
easy
for
you
to
take
kind
of
for
loops
or
iterators
that
you
were
doing
and
make
them
run
in
parallel,
and
so
some
function
that
took
too
long
should
take
less
time
and
people
often
call
that
data
parallelism.
And
so,
if
you
look
at
this
piece
of
code
right,
this
is
a
sequential
loop
using
iterators
to
load
a
bunch
of
images
off
the
disk.
A
And
so
probably
many
people
here
are
familiar
with
iterators.
But
the
basic
idea
is
right.
You
have
to
start
with,
in
this
case
a
slice
so
like
an
array
of
paths
and
we're
gonna
create
an
iterator
and
that's
a
little
thing
that
it
doesn't
actually
do
anything.
Yet
it
lets
me
build
up
something
that
describes
what
to
do
when
I
actually
do
the
loop
right
so
initially,
I
have
just
this
blanket
iterator.
That
would
just
be
saying:
okay
go
up
and
give
me
one
path.
A
Give
me
each
path
as
I
go
through
and
then
I'm
gonna
call
map
and
what
that
says.
It's
kind
of
for
each
path.
I'm
gonna
invoke
this
function,
which
is
gonna,
call
image
load,
so
I
had
paths
now,
I'm
gonna
have
actually
images
loaded
off
the
disk,
but
I
still
haven't
done
anything
yet
I'm,
still
just
building
an
iterator,
describing
what
I
will
do.
They're
kind
of
lazy
like
that
right
and
here
when
I
call
collect
that's
when
the
actual
iteration
happens,
so
it
starts
to
iterate
through
for
each
path.
A
It's
gonna
call
image,
load
and
we'll
end
up
with
a
set
of
images
which
will
store
into
a
vector,
and
we
figure
out
that
we
want
a
vector
because
that's
the
return
type
of
this
function.
So
what
I'd
like
you
to
be
able
to
do
is
say
well,
loading.
An
image
is
something
that
I
could
easily
do
in
parallel.
A
So
why
don't
I
just
do
that
by
changing
a
dirted
operator,
and
ideally
that's
all
you
have
to
do
and
in
fact
which
way
on
that
is
all
you
have
to
do,
except
you
have
to
add
one
import
that
I
didn't
show
use
rayon
quaalude
star,
so
that's
pretty
cool
all
right
and
you
can
now
load
a
full
directory
of
images
and
it'll
go
a
little
bit
faster,
but
there
are
a
lot
of
languages.
Actually
that
will
let
you
do
things
like
this,
but
one
of
the
catches
is.
A
You
have
to
know
that
it's
safe
to
do
it
in
parallel
right,
it's
very
easy
to
think
something
safe
to
do
in
parallel,
but
actually
maybe
you'll
get
different,
surprising
results
where
your
program
doesn't
work.
So
here's
an
example
of
something
you
might
have
done.
You
might
have
had
a
little
counter
and
you
were
trying
to
track
here.
You
go.
This
is
what
I
added
right
choice,
trying
to
track
how
many
ping
files
you
had
as
you
went
through.
So
you
have
a
counter
and
you
add
one
to
it
as
you
go.
That
seems
fine.
A
They
both
have
one
now
and
they
both
store
one.
We
should
have
two,
but
we
only
have
one
is
the
total
count
and
what's
kind
of
nasty
about
these
bugs?
Is
that
a
lot
of
times
they
don't
show
up
very
consistently
right,
so
it
might
work
just
fine
on
your
computer.
Maybe
you
only
have
two
cores
or
something
and
they
rarely
conflict,
but
once
in
a
while
or
maybe
you
have
a
big
directory
of
full
of
images,
and
so
the
right
count
is
1556
and
your
count
is
1442.
A
And,
of
course,
you
didn't
actually
count
them
by
hand,
so
you
don't
know
that
it's
wrong
and
your
program
just
keeps
going
right,
but
in
rest,
if
we
use
beyond
what
will
happen,
is
we
just
won't,
compile
it
all
right,
so
the
goal
is
kind
of.
When
you
add
this
part
it
or
not.
Only
should
it
work
in
parallel
and
hopefully
run
faster.
If
you
have
enough
work
to
make
it
worthwhile,
but
in
case
there
is
actually
a
problem,
it
should
let
you
know
right.
A
So
don't
just
go
and
do
the
wrong
thing,
and
there
was
a
fun
blog
post,
not
written
by
me
that
kind
of
went
into
this
or
someone
added
in
Rayong
and
they
got
some
errors
and
when
they
traced
it
out,
it
turned
out
that
there
was
basically
this
same
bug.
I
just
showed
you
where
a
counter
was
getting
incremented,
but
it
wasn't
like
in
one
function
and
easy
to
see.
It
was
spread
apart
several
modules
and
it
would
have
taken
them
forever
to
track
it
down,
but
it
just
didn't
happen
at
all.
A
In
the
first
place,
they
weren't
happy
about
that
and
I
was
happy
because
they
wrote
a
cool
blog
post.
So
this
is
the
structure
of
rayon,
and
it's
also
the
structure
of
my
talk,
rands
kind
of
broken
up
into
several
layers
right.
There
are
these
parallel
iterators
that
I
just
showed
you
and
those
are
actually
essentially
all
safe
code.
They're,
like
a
library
written
on
top
of
a
more
fundamental
abstraction
and
that's
called,
join
and
join
offers
up
a
safe
interface
that
lets.
A
A
The
basic
idea,
the
basic
reason
that
sequential
and
parallel
is
not
always
the
same-
is
that
sequential
goes
from
left
to
right
all
the
time
right,
but
in
parallel
the
whole
point
is
we
want
to
process
in
any
order,
and
sometimes
more
than
one
at
a
time
right,
and
that
means
that
some
things
that
we
used
to
do
just
don't
make
sense
in
that
setting
right
so
ideally
would
always
be
as
simple
as
changing
dot
iterative
part
to
dot
parter.
But
it's
not
always
quite
that
simple.
A
There
are
a
few
things
that
might
lead
to
two
surprises:
the
first
one
we
already
saw,
which
is
that
you
can't
really
mutate
shared
state
in
these
two
videos,
because,
as
we
saw
like
when
you
try
to
both
increment
a
counter,
you
might
get
confused
and
another
problem
is
that
some
of
the
iterator
combinators
actually
just
don't
make
sense
in
parallel
at
all
like
fold
as
we'll
see,
and
so
we
have
to
do
different
combinators
that
work
a
little
bit
differently.
And
finally,
this
is
a
spare
time
project
a
lot
of
times.
A
A
I
showed
you
before,
where
you
have
this
counter
and
I
said
it's
bad,
because
you're
gonna
be
incrementing
it
in
two
different
threads,
and
we
don't
want
to
do
that,
and
you
might
infer
from
this
that
maybe
you
can't
do
any
mutation
at
all
when
you're
doing
parallel,
iteration
and
a
lot
of
people
I
think
equate
these
sort
of
things
they
said
well,
if
I'm
gonna
do
parallel,
iteration
I
really
need
or
a
parallel
work.
I
really
need
a
functional
approach.
I
can't
do
any
mutation
and
so
on.
A
That's
not
really
true,
it
is
helpful,
but
it
is
perfectly
fine
to
mutate
in
parallel
as
long
as
you're
mutating
different
things
right.
So
here's
an
example
where
I
have
a
function
that
has
a
mutable
slice
of
integers
which
it
goes
over,
and
this
is
still
sequential,
of
course,
and
it's
calling
it
ER
mute.
A
So
if
you
haven't
used
it
ER,
ators
too
much
the
difference
between
it,
ER
and
inter
mute,
is
that
it
ER
mute,
gives
you
a
mutable
reference
into
the
elements,
so
you
can
kind
of
change
them
as
you
iterate
over
them
in
place
right.
So
here
this
variable
C
is
going
to
be
basically
first
a
reference
to
the
first
thing
in
the
slice,
then
the
second
one
and
the
third
one
and
so
on,
and
so
for
each
one
we're
gonna
increment
it
so
effectively.
A
A
Of
course
we
do
pirate
or
mute
to
go
into
the
parallel
mode,
and
then
we
have
to
do
this
dot
for
each
that's
because
for
in
rest,
is
like
the
sequential
syntax
it's
kind
of
built
into
the
language,
so
we
use
for
each
instead,
so
that
I
can
actually
run
it
in
parallel.
But
essentially
it's
the
same
idea
right.
We're
gonna
call
this
closure
for
all
the
things
in
parallel
and
it
has
a
reference
C
pointing
into
the
array
and
it
can
increment.
A
So
this
is
exactly
equivalent
right
and
the
key
point
is
the
data
was
not
shared
between
the
iterations,
the
data
we
were
going
to
mutate,
so
sometimes
that
will
be
because
we've
used
something
like
para
term
ute,
that's
kind
of
subdividing,
an
array
into
lots
of
disjoint
mutable
pieces,
each
one
separate
and
sometimes
it
might
be,
because
you've
just
got
immutable
well,
I'm,
not
so
much
with
parallel
iterators.
But
more.
A
If
you
were
using
join,
which
lets
you
start
two
threads,
you
might
have
some
mutable
data
that
goes
to
one
thread
and
other
immutable
data
that
goes
to
the
other
and
that's
perfectly
fine.
As
long
as
the
same
mutable
data
doesn't
try
to
go
to
both
right.
So,
okay,
that's
good,
but
how
could
I
in
Christ
ill
want
to
count
all
the
pings
in
my
directory
right,
I?
Don't,
and
how
can
I
actually
do
that?
There
are
a
couple
ways
you
could
do
it.
One
way
might
be.
You
might
split
this
loop
up.
A
Instead
of
doing
everything
in
one
walk
over
the
list
of
pads,
you
might
do
two
so
here
you
would
have
this
first
pass
where
you
iterate
over
the
paths
and
we
filter
out.
So
we
just
select
only
the
pads
that
end
in
ping
and
then
we
call
dot
map
to
convert
each
one
of
those
to
the
number
one,
and
then
we
add
up
all
the
numbers
ones.
You
could
also
call
dot
count,
except
that
I
hadn't
implemented
it
when
I
made
these
slides,
but
I
recently
opened
a
PR
this
morning.
A
A
You
size
right
and
we
can
make
it
like
this,
so
let
pings
equals
atomic
you
size,
new,
0
and
now
pings
is
going
to
be
also
still
an
integer,
but
it's
one
that
we
can
only
access
through
the
atomic
you
size
API
in
the
atomic
you
size,
API
is
kind
of
special
because
since
when
I
told
you
that,
normally
when
you
increment
things,
it's
a
three-step
process
where
you
read
the
value,
add
1
and
write
it
back.
Atomic
you
size
makes
sure
that
all
of
those
steps
are
done
without
anybody
else
interrupting
you.
A
A
Another
thing
I
strongly
recommend
is
that
you
at
least
start
with
the
sequentially
consistent
ordering,
especially
if
you
don't
know
what
I'm
what
that
means.
Basically,
that
means
things
work
like
you
expect
them
to,
and
so
what
this
will
do
is
this
will
exactly
like
before.
So
when
in
the
sequential
code,
pings
was
a
counter
that
was
kind
of
saying
how
many
pings
had
I
seen
so
far
right
and
when
I
should
I
mean
when
I
go
back
to
the
old
version
here,
where
I
broke
pings
out
into
a
separate
loop.
A
That
was
a
little
bit
different
right,
because
now
pings
wasn't
the
counter
of
how
many
I'd
seen
so
far.
It's
a
count
of
the
total
number.
So
if
we
want
to
go
back
to
how
many
we've
seen
so
far,
we
can
use
atomic
you
size.
So
now,
again,
pings
is
representing
how
many
have
I
seen
so
far,
but,
unlike
in
the
sequential
case,
that's
not
an
easy
thing
to
think
about
right
before
it
was.
A
Oh,
it
didn't
in
the
sequential
case
it
didn't
change
as
we
were
going
because
it
was
just
all
the
people
to
the
left
and
they
were
waiting
for
me,
but
here
there
might
be
other
people
going
at
the
same
time.
So
every
time
I
read
pins
even
in
two
lines
right
next
to
each
other,
I
might
get
different
values
right
and
that's
why
I
suggest
that
that's?
A
Why
I
say
that
you
can
do
this
if
you
want
to
have
a
counter
that
you're
incrementing,
but
you
know,
use
it
at
your
own
risk
because
it's
very
easy
to
forget
that
two
lines
right
next
to
each
other
can
get
interrupted
by
other
operations.
So
another
thing
you
could
do
is
use
a
mutex
of
integer
and
so
forth,
but
I
think
at
that
point
it's
over
overkill.
For
this
example.
Let's
say
any
case.
The
main
thing
is
there:
are
these
Atomics,
so
you
can
do
writes
if
you
really
want
to.
A
But
you
have
to
be
aware.
This
is
where,
if
you
don't
use
the
tommix,
essentially
your
code
should
either
compile
and
do
pretty
much
the
same
thing
or
not
compile.
For
some
reason
for
use
Atomics,
it
starts
to
be
that
it
could
compile,
but
acting
in
quite
different
ways,
because
you've
added
all
the
lot
of
threads
into
the
system.
So
that's
that's.
Shared
State
I
also
mentioned
that
some
Combinator's
just
don't
make
sense
in
parallel
and
here's
an
example
of
one.
A
So
this
is
a
sequential
loop
standard
iterators
and
it's
doing
this
thing
called
a
dot
product
which
you
may
remember
from
math
I
didn't
but
I
like
to
use
it
anyway,
like
I,
remember
the
name
right
so,
basically
what
a
dot
product
does.
It
takes
two
big
vectors
of
numbers
that
are
the
same
length
and
it
walks
over
them
in
lockstep
right.
So
we
might
start
with
the
three
and
the
two
from
these
two
vectors.
We
multiply
them
together.
A
That's
what
this
map
is,
and
that
gives
us
a
number
like
here:
six,
that's
the
product
of
the
two
and
then
we
add
up
all
those
products,
and
we
can
do
that
ad.
We
could
call
dot
sum,
but
this
is
what
dots
does
is
actually
just
called
bat
fold.
So
we
can
use
this
operation
called
fold
and
what
a
full
does
is
it
has
like
an
accumulator
and
then
the
thing
that
keeps
getting
accumulated
in
with
this
closure
in
operation,
so
in
this
case
we'll
be
accumulating
by
adding
alright.
A
So
we
start
out
with
zero,
that's
the
initial
value
of
our
accumulator
and
then
we
take
six
and
we
add
them
together
and
that's
our
new
accumulator.
So
the
sum
so
far
is
six
and
then
we
would
go
to
the
next
item
here
we
have
two
and
one
we
multiply
them.
We
add
it
in
our
number
change
to
eight
and
we
can
kind
of
keep
doing
this
and
we'll
eventually,
if
I
typed
it
in
my
computer
right
we'll
get
82
right,
that's
our
dot
product
and
you
can
see
that
this
is
this
fold.
A
Operation
is
very
sequential,
it
said
start
with
an
accumulator.
Take
the
next
item
put
it
in
take
the
next
item
put
it
in.
It
doesn't
really
make
sense
to
paralyze
it.
So
if
you
go
in
parallel,
there
is
something
that
you
can
use
to
do
parallel
sums,
but
it
works
a
little
differently
and
so
I
gave
it
a
different
name
to
kind
of
warn
you.
So
this
is
another
case
of
the
code
won't
compile
if
it
wouldn't
do
kind
of
the
same
thing.
A
So
this
thing
is
called
reduce
and
reduce
kind
of
works
like
fold,
except
that,
instead
of
starting
from
the
left
and
going
to
the
right,
it
essentially
breaks
your
your
list
into
little
pieces.
Independent
pieces
and
rayon
will
figure
out
kind
of
automatically
how
big
these
pieces
should
be
or
try
to
write,
and
it
will
do
them
all
in
parallel
with
one
another
and
within
any
individual
piece,
you're
essentially
doing
a
fold
alright.
So
we
might
start.
We
have
now
here
three
chunks
and
we
can
compute
three
partial
sums.
A
We
have
twenty
for
the
first
four
and
then
19
for
the
next
four
and
then
43
for
the
last
three
and
now
that's
good,
and
then
we
have
to
combine
those
partial
sums
to
get
the
total
sum
over
the
whole
thing
right.
So
then
we
would
add
20
in
nineteen
and
we
get
39
and
we
add
in
43
and
we
get
82.
You
can
see
this
worked
a
little
bit
differently.
A
Not
only
did
it
not
go
from
left
to
right,
but
one
other
more
subtle
difference
was
that
this
closure,
the
a
plus
B
in
the
fold
case.
The
B
value
was
always
something
coming
out
of
the
iterator
and
a
was
always
the
accumulator.
So
they
could
even
have
different
types.
They
don't
have
to
be
the
same
sort
of
value.
In
the
reduce
case,
the
a
plus
B,
the
a
and
B
can
sometimes
be
things.
A
One
is
an
accumulator
and
one
is
a
thing
you're
iterating
over
that's
when
you're
computing
that
first
row,
but
then,
after
that
the
a
plus
B,
the
a
might
be
20
and
the
B
might
be
19.
Those
are
partial
sums.
They
never
appeared
in
our
iterator
right,
so
the
types
have
to
be
the
same,
and
so
that
kind
of
shows
up
in
the
signature.
So
we
essentially
reduce
probably
most
folds
that
you
do
in
practice.
Reduce,
probably
works.
Just
fine,
but
not
all
I
need
to
be
a
little
careful.
A
You
particularly
want
I
think
it's
commutative
operations,
or
maybe
it's
associative
associative,
the
ones
that
you
can
change
the
parentheses
I,
always
get
them
mixed
up.
Okay,
so
in
summary,
parallel
iterators
are
basically
mostly
like
normal
iterators,
but
you
can't
mutate
shared
state
and
you
have
to
watch
out
for
some
operations
that
are
just
a
little
different.
A
You
might
depends
what
you
want.
So
the
goal
is
that,
for
the
most
part,
rust
and
the
design
of
rayon
will
protect
you
from
surprises
by
saying,
if
it
compiles,
it
should
kind
of
work
like
you
expects,
and
otherwise
B
you'll
try
to
do
it.
You
may
have
to
make
some
small
changes
all
right.
So
that's
how
parallel
iterators
work
and
what
I
want
to
do
now
is
take
a
step
down
and
look
at
how
they're
actually
implemented
and
how
the
thread
pool
works.
A
You
don't
know
if
they're
playing
an
mp3
in
the
background,
that's
taking
up
one
of
the
cores
or
not
it's
hard
for
you
to
judge
just
how
many
threads
do
you
want,
so
a
rayon
tries
to
do
is
look
dynamically
using
these
schemes
and
figure
out
how
many
threads,
when
it
makes
sense
to
split
work
and
so
on.
So
you
might
wonder,
like
okay,
that
join
makes
sense
and
parallel
iterators
make
sense.
But
how
do
I,
how
would
I
ever
get
between
them?
They
seem
pretty
different.
A
Well,
the
way
it
works
is
basically
something
called
divide
and
conquer,
which
is
this
common
strategy.
We
can
use
a
lot.
So
basically,
a
parallel
iterator
starts
out
and
says:
I
have
a
big
pool
of
work
to
do.
I
have
to
go
over
all
of
these
paths,
so
that's
like
my
first
job
and
I
also
have
this
tool
joins.
What
I'm
gonna
do
is
make
my
work
easier.
A
A
Maybe
it's
1,
maybe
it's
a
little
more
and
then
we'll
actually
execute
the
iterator
just
sequentially
like
normal,
so
here
this
first
job
would
actually
call
image
loaded
paths
of
0
effectively
and
the
second
job
would
load
image,
loaded
paths
of
1
right
and
then
this
would
filter
back
up
now.
I
said
that
join
doesn't
always
start
new
threads
right,
so
conceptually
I'm
kind
of
starting
new
threads
and
it's
always
safe
to
do
so.
But
how
is
it
really
implemented
at
runtime?
A
The
idea
is
that
we
wind
up
having
one
thread
roughly
per
CPU
in
your
system
and
those
are
the
worker
threads,
and
then
we
have
those
things.
Those
things
that
go
to
join
those
are
called
tasks
and
we're
gonna
kind
of
multiplex
them.
We're
gonna,
have
the
worker
threads
share
that
pool
of
tasks
that
are
available
and
do
as
much
work
as
they
can
when
they
can
and
we're
using
a
technique
called
work-stealing,
which
was
I,
think
pioneered
and
invented
by
the
people
who
did
soap,
but
it
was
at
least
popularized
by
them.
A
A
I
just
work
queue,
so
those
thread
might
start
out
with
a
job
like
process
the
whole
array
from
0
to
22,
and
so
it's
gonna
split
that
and
call
join
and
what
join
does
is
it
takes
one
of
those
closures
and
sticks
it
on
this
list
of
work
to
do
later,
that
will
be
15
to
22,
and
then
it
just
starts
right
in
on
the
on
the
other.
One
just
calls
it
like
normal.
A
So
now
0
to
15
is
executing,
and
this
will
again
split
and
we'll
put
one
on
the
queue
for
later
and
we'll
do
this
0
to
1
and
maybe
we'll
finish
that
job
right
and
then
what
do
we
do
when
we
finished
a
job?
Is
we
go
back
to
our
list
of
stuff
to
do
later
and
we
take
the
thing
off
the
top.
The
most
recent
thing
so
we'll
go
over
here
and
start
doing,
1
to
15
right
and
that's
kind
of
thread,
a
but
thread.
A
B
is
just
sitting
around
twiddling
its
thumbs
and
nothing
to
do
and
threads
don't
like
to
be
idle.
So
what
thread
B
will
do
is
say:
I'm
gonna
go
look
for
work
to
do
and
it
goes
when
it
has
nothing
else
to
do.
It
goes
and
looks
at
other
threads
to
see
if
they
have
any
work
on
their
list
that
they
haven't
started
yet,
and
we
call
that
work
stealing
right.
A
It's
kind
of
a
funny
term,
because
it's
like
a
thief
breaks
into
your
house
and
says:
look
this
guy's
a
pile
of
wonder
dirty
dishes,
I'm
gonna
start
doing
those
I'll
be
helpful.
So
you
know
it's
a
nice
thing,
so
the
thread
becomes
in
Steel's
15
to
22,
to
help
thread
AAA
out
and
thread.
B
then
does
basically
the
same
thing.
It
splits
it
up
into
two
jobs
puts
one
on
its
list
of
work
to
do
later
and
goes
in.
Does
it
again?
A
It
goes
down
the
left
side,
and
here
it
actually
finishes
a
work
item.
So
it
does
exactly
what
thread
a
did
pulls
off
the
top
thing
on
its
queue
and
starts
doing
that.
But
meanwhile,
while
thread
B
is
doing
all
that
stuff
thread,
a
is
probably
finished
with
the
work
it
was
doing.
So
it's
gonna
come
back
and
try
to
go
to
this
next
thing.
That
was
on
its
queue
right
only
that
got
stolen.
So
that's
not
really
left
for
us
to
do
so
now
thread
a
has
nothing
do
so.
What
does
it
do?
A
A
That's
okay,
because,
if
thread
a
gets
stuck
doing,
one
image
that
B
can
just
keep
stealing
work
and
it's
fine
right,
it'll
kind
of
fill
in.
So
that's
the
basic
idea
and
there
are
ways
to
make
it
better.
For
example,
there
was
a
recent
PR
that
I
thought
was
really
cool,
so
I
wanted
to
highlight
this
was
Josh
stone
or
COO
VIPRE
his
contribution
that
basically
refines
that
idea
by
also
being
a
little
bit
more
concerned
by
being
careful
about
when
to
actually
join
so
it
uses
tricks
like
trying
to
gauge.
A
A
That's
really
most
of
the
big
ideas
in
ran
right,
so
essentially
we
have
the
parallel
iterators
and
the
join,
and
together
using
these,
we
can
kind
of
easily
add
parallelism
into
our
programs,
sometimes
just
because
it's
cool,
sometimes
because
it's
actually
running
slowly
and
there's
a
bunch
of
different
API
is
available.
So
there's
actually
a
third
API
I
didn't
have
time
to
talk
about
called
scope
that
is
sometimes
kind
of
an
alternative
to
join.
It's
good
for
other
situations.
A
It's
kind
of
nice
to
read
the
library
and
figure
out
which
is
the
best
for
your
particular
task
and
there's
a
lot
of
cool
directions
that
we
can
take.
This,
of
course,
can
always
have
more
iterators,
but
there's
also
I
think
it
should
be
possible
to
do
things
like
automatically
convert
to
symbiotes
and
integrate
nice
data
structures
like
persistent
trees
and
maybe
factor
out
this
thread,
pool
into
something
that
lots
of
projects
could
use
not
just
rayon,
so
I'm
excited
to
see
where
the
future
goes
thanks.
Everybody.