►
From YouTube: Nicholas Matsakis: RUST:Reach Further
Description
Rust is a new programming language that is growing rapidly. Rust's goal is to help in writing programs that are at once correct and efficient. Rust offers performance comparable to C++ and, like C++, has minimal runtime requirements -- it does not require a runtime or garbage collector, and you can even choose to forego the standard library. At the same time, Rust offers some of the strongest safety guarantees around -- not only type and memory safety, but also data-race freedom!
A key part of Rust's design is that the language itself doesn't "privilege" one form of parallel programming over the others.Instead, Rust supplies two core primitives -- ownership and traits -- that enable libraries to implement a wide variety of parallel styles. Currently, libraries exist to support newer models like actors and futures, but also more traditional threaded programming based on locks. There are also a host of non-blocking data structures available, as well as a work-stealing runtime that makes data parallelism very easy.
This talk will cover some of the highlights of Rust's design, and show how Rust's type system not only supports different parallel styles but also encourages users to write code that is amenable to parallelization. I'll also talk a bit about recent work at Mozilla, where Rust was instrumental in parallelizing parts of Firefox's CSS engine.
B
So,
let's
start
with
safe,
we
hear
the
word
safe
used
to
mean
a
lot
different,
a
lot
of
different
things,
so
I
mean
it
in
a
sort
of
particular
way
if
you've
ever
written
any
c
and
c++
code
you'll
be
familiar
with
these
kinds
of
bugs
that
I'm
showing
you
here
on
the
screen.
These
are
like
the
nightmare
of
all
C++
programmers
right
and
it's
because
they're
kind
of
hitting
these
three
things
that
are
really
bad
to
have
all
together.
B
First
they're
really
hard
to
find
and
understand
what's
wrong
because
they
manifest
in
some
error,
but
the
actual
cause
is
usually
quite
distant
from
that
particular
problem
you're
seeing.
Secondly,
they
can
have
really
severe
consequences
like
security
vulnerabilities
or
just
kind
of
arbitrary
behavior
on
the
part
of
your
program
and
finally,
they're
really
common.
It's
almost
impossible
to
write
a
significant
amount
of
C
in
C++
code
without
bugs,
like
these
occurring
fairly
regularly
all
right
in
at
Mozilla
where
I
work.
B
We
have
we
write
when
we
make
Firefox
and
there's
I,
don't
know
how
many
millions
of
lines
of
C++
code
in
there
and
I
can
assure
you
it's
full
of
these
kinds
of
bugs,
as
is
every
other
project
of
that
size,
even
though
we
run
linters,
even
though
we
do
all
kinds
of
things
to
find
those
problems,
so
fuzzing
and
so
on.
So
you
might
think
well,
I
think
we
kind
of
solved
this
already.
We
had
this
thing
called
a
garbage.
B
Collector
we've
had
it
for
a
long
time,
they've
been
getting
better
and
better,
and
it's
true
that
a
garbage
collector
kind
of
handles
the
first
three
problems
here.
Pretty
well,
it's
kind
of
got
the
sequential
code
working
well
as
long
as
there's
some
runtime
implications.
That
may
be
a
problem
for
you,
but
those
can
be
tuned,
but
this
last
problem-
data
race
is
a
garbage.
Collector
alone
does
nothing
to
really
help
you
here
and
if
you've
ever
written
a
lot
of
java
code,
especially
multi-threaded
java
you'll,
know
what
I'm
talking
about
right.
B
B
A
lot
of
this
excellent
type
system
research
and
apply
it
and
put
it
to
use
in
preventing
all
these
sorts
of
bugs,
but
not
through
a
runtime
mechanism
like
a
garbage
collector,
but
through
the
type
system,
detecting
and
guaranteeing
that
you
don't
have
these
problems
upfront
in
order
to
get
your
code
to
compile
right
and
it
can
be
a
bit
of
a
hard
sell.
I
have
to
tell
you
when
I
talk
to
people
and
I,
say:
hey
I!
Want
you
to
use
this
fancy
type
system.
It's
gonna!
B
Give
you
safety
guarantees
a
lot
of
times
what
they
hear
is
kind
of,
like
your
mom
saying,
or
your
parents,
I
should
say,
saying:
eat
your
vegetables
right.
It's
like
I
know
it's
good
for
me,
but
it's
not
really
what
I
want
I.
What
I
want
to
do
is
ship
this
thing
tomorrow,
and
this
is
just
getting
in
my
way.
That's
not,
however,
how
I
see
it.
I
see
safety
guarantees.
B
They
are
spinach
but
they're
like
Popeye
spinach,
right
they're,
the
kind
of
thing
that
lets
you
take
this
code
and
actually
make
it
work
for
real
right
and
I'm.
Gonna.
Give
you
some
examples
as
we
go
of
what
I
mean
by
this,
how
this
is
playing
out
sort
of
in
real
life,
but
here's
one
example
that
came
from
sort
of
in
the
wild
I've
actually
had
almost
the
same
experience
as
this
fellow.
B
It
was
because
there
was
a
subtle
race
condition
that
would
have
arisen,
probably
not
right
away
down
the
line,
and
instead
he
learned
about
it
right
away
and
he
was
able
to
fix
it
right,
and
so,
basically,
what
it
is
is
when
you're
working
with
these
safety
guarantees
the
some
portion
of
your
brain
that
is
dedicated
to
making
sure
those
bugs
don't
happen,
gets
to
work
on
other
things
right
and
you
don't
have
to
worry
about
the
maintenance
problems
of
well.
If
I,
do
this
really
clever
parallelization
scheme?
B
What's
gonna
happen
when
I
leave
and
two
other
programmers
come
and
get
hired,
and
maybe
they
don't
understand
it
and
they
start
hacking
on
the
system?
Is
it
going
to
break
then
those
kind
of
problems
you
don't
have
to
worry
about,
because
if
they
do
that,
the
compiler
will
tell
them
so
all
right.
That's
safety.
What
fast!
Well,
we
all
kind
of
know
what
fast
means
right,
but
and
here
again
I'm
kind
of
aiming
at
some
particular
specific
meanings.
B
We
would
like
to
be
able
to
support
code,
that's
comparable
to
C++
in
terms
of
how
fast
you
can
make
it
go,
and
one
of
the
things
we
really
want
to
support
is
the
C++
notion
of
a
zero
cost
abstraction.
This
is
something
that
C++
does
really
well
and
I.
Think
it's
not
so
well
understood
outside
of
that
community.
It's
basically
the
idea
that
you
should
be
able
to
use
high
level
looking
language
features
and
they
should
compile
down
to
very
efficient
assembly,
and
they
should
do
that
without
the
need
for
heroic
compiler
optimizations.
B
B
The
problem
is
in
C++
if
you're
wrong,
you
end
up
with
a
crash
or
something
else,
and
that's
where
the
safety
guarantees
come
in
right,
but
we
also
mean
stuff
like
not
having
a
garbage
collector,
because,
despite
all
the
work
that's
gone
in,
there
are
still
a
lot
of
problems
around
garbage
collection
in
practice,
especially
in
big
servers
or
areas.
Where
memory
is
a
problem,
you
can
wind
up
consuming
a
lot
more
memory.
B
You
can
wind
up
with
surprising
pauses
when
you
don't
want
them
that
sort
of
thing
so
we'd
like
to
find
a
way
to
not
have
those
problems
and
we'd
also
like
to
build
a
managed
other
kinds
of
resources.
Besides
memory
like
resources,
sockets
we'll
see
some
examples
where
we
take
advantage
of
that,
and
the
nice
thing
is
once
you
don't
have
a
mandatory
garbage
collector.
Actually
rust
goes
a
little
bit
further.
B
We
don't
really
have
any
mandatory
runtime
at
all,
so
you
don't
even
need
a
memory
allocator
if
you
want
to
compile
to
some
target
that
doesn't
have
malloc
it's
kind
of
like
C
in
that
way
right.
So
all
these
projects,
where
you
would
have
thought
you
have
to
use
C
we'd
like
you
to
be
able
to
use
rust.
B
So
if
you
have
a
big
chip,
Java
project,
a
big
Ruby
project-
and
you
want
to
take
some
of
that
code
and
convert
it
into
say
rust
code
and
then
plug
it
into
the
Ruby
VM,
that's
okay,
all
right!
We
can
do
that.
So
here's
an
example
of
that
this
is
some
Ruby
code
that
that
is
used
to
test.
If
a
string
is
whitespace,
this
was
in
the
I,
don't
know
if
it's
still
there,
but
it
was
at
some
time
the
actual
definition
of
that
method.
B
In
Ruby
it
uses
a
regular
expression,
as
you
can
imagine
it's
not
all
that
fast!
It's
okay!
You
know!
How
often
do
you
check
if
a
string
is
whitespace?
Well,
it
turns
out
if
you're
running
Ruby
on
Rails,
you
check
that
a
lot
like
every
time
that
a
request
comes
in
because
you
want
to
look
at
the
URL
and
so
some
enterprising
programmer
said.
Well,
you
know
what
we
can
do.
We
could
rewrite
that
in
C.
That's
fine,
and
so
this
is
what
it
looks
like
it's
a
little
longer,
it's
got
some.
B
If
you
look
closely
you'll
see
it
has
a
lot
of
Unicode
assumptions
baked
in
there's.
Also
some
rossi
pointers
running
around
and
I
think
it's
correct
as
far
as
I
know,
but
it
could
easily
be
wrong
and
it
could
easily
have
devastating
consequences
in
that
case,
but
let's
assume
it's
correct
so
when
they
do
this,
Sam
saffron
did
this
by
the
way.
If
you
run
Ruby
on
Rails,
you
should
use
that
gem
I
understand
it's
good,
because
it
goes
about
10x,
faster.
B
This
function
right
and
then
that
takes
it
out
you're
out
of
your
Ruby
on
Rails
profile.
Well,
he
also
later
we
wrote
it
in
rust,
so
that
was
what
we
saw
before
he
rewrote
it,
and
this
is
the
rust
version
right
and
you
can
see
it's
quite
a
bit
nicer
than
the
C
one.
Actually
I
think
this
was
his
prototype.
He
was
expecting
to
make
it
longer
and
bigger.
This
was
just
though,
let's
just
get
it
working
version.
B
It
uses
a
lot
of
high-level
stuff
like
this
slice,
which
is
like
an
array
with
bounds,
checking
an
iterator
over
all
the
characters
in
that
slice,
a
closure
and
the
tests
if
it's
white
space
and
but
it
all
compiles
down
to
thanks
to
the
zero
cost,
abstractions
the
same
kind
of
code.
You
saw
and
see
right.
So
it
runs
the
same
performance
and
that's
the
kind
of
thing
we
want
to
show,
and
we
can
go
further
than
that.
That's
the
is
white
space.
B
We
could
build
higher
level
abstractions,
like
I'll
talk
a
little
bit
about
we're
in
a
multi-core
conference,
our
parallel
iterators
that
do
the
same
thing,
but
they
would
distribute
it
over
your
cores
using
a
work-stealing,
runtime,
etc,
etc,
and
I
should
mention
if
you've
written
C
in
C++
code,
especially
if
you've
used
Auto
tools,
you'll,
be
glad
to
know.
We
make
it
really
easy
to
take
advantage
of
other
people's
libraries
so,
like
all
these
abstractions
are
great.
B
But
if
you
have
to
download
and
run
a
bunch
of
stuff
and
hope
that
it
compiles
not
so
convenient
it's
much
nicer.
If
you
can
just
add
a
few
lines
and
have
the
package
manager
download
it
for
you
and
all
that
stuff,
we
do
that
too.
Ok,
so
that
was
fast.
Let's
talk
about
works,
real
fast
and
then
I'll
get
to
the
heart
of
the
talk.
So
I
mean
kind
of
a
pun.
Here,
I
guess
works
I
mean
both
that
people
use
it
at
work.
B
B
You
will
know
on
there
mozilla,
dropbox
and
PM,
and
I
also
mean
that
rust
has
that
quality,
which
I
think
is
shares
with
a
lot
of
functional
languages
and
other
languages
that
once
you
get
things
to
compile
it,
they
tend
to
work
in
practice
a
lot
better
than
what
you
may
be
used
to
in
other
languages
right,
and
I
think
that's
because
they
encourage
you
to
be
bulletproof.
Basically,
they
make
you
handle
a
lot
of
cases,
and
the
end
result
is
that
your
code
actually
works
when
those
cases
inevitably
come
up
in
practice
right.
B
So
if
you
use
C
and
C++
already,
we
think
rust
can
help
you
do
more
than
what
you're
able
to
do
today
right,
because
you
can
take
energy
and
do
more
aggressive
designs
and
not
worry
as
much
about
maintenance
costs
and
all
that
stuff.
If
you
don't
Russ,
may
give
you
another
window
a
way
to
go
from
Ruby
to
something
that's
faster,
to
eliminate
a
hotspot,
use,
more
parallelism
and
so
on.
B
A
B
Come
hang
out,
ask
us
questions,
we'd
love
to
answer
them
alright.
So
this
is
what
I'm
going
to
cover
in
this
talk.
I'm
gonna
go
through
a
lot
of
I'm
gonna
start
with
this
concepts
of
ownership
and
borrowing.
These
are
the
things
that
make
rust
sort
of
tick,
how
we
get
those
safety
guarantees
and
then
I'm
gonna
use
those
and
show
you
how
we
can
use
them
to
do
a
lot
of
different
parallel
abstractions,
like
everything
from
shared
memory,
with
locks
to
sending
data
over
channels
and
so
forth.
B
All
without
any
data
races,
I'll
talk
a
little
bit
about
unsafe,
rust
and
show
where
what
happens
when
you
need
to
go
past
those
rules
and
what
how
could
we
handle
that
and
then
some
of
our
experiences
using
it
at
Mozilla
and
so
on.
So
let's
talk
about
ownership.
First,
one
of
the
surprises
that
came
along
the
way
from
working
on
rust
is
the
way
we
handle
parallelism
at
first.
B
We
thought
there's
only
one
example
of
a
language
that
lets
you
write
parallel
code,
that's
not
horribly
bad
and
that's
Erlang,
so
we
should
clearly
adopt
the
Erlang
model
100%.
We
were
gonna
have
separate
tasks
with
Shepherd
memory
spaces,
and
that
was
the
way
we
were
going
to
go.
But
what
we
found
over
time
was
that
actually
a
shared,
the
kind
of
threads
plus
shared
memory
model
wasn't
as
bad
as
we
thought
sure
it
could
be
made
to
work
and
we
can
model
the
rest
of
the
stuff.
B
On
top
of
that
that
we
wanted
and
the
way
that
that
kind
of
came
about.
Well,
we
didn't
expect
that
right,
I
mean
we
have
a
lot
of
bad
experiences.
This
sign
shows
this
is
a
Mozilla
distinguished
engineer,
very
smart
fellow.
He
has
this
sign
in
his
office
right.
It
says
you
have
to
be
this
tall
like
taller
than
anybody
else
to
handle
multi-threaded
code
and
that
was
kind
of
what
we
assumed
also.
But
if
you
look
more
closely,
you
see
that
there
is
a
way
to
prevent
data
races
actually
right.
B
So
so
the
reason
that
multi-threaded
code
is
so
painful
is
these
data
race
conditions,
where
you
have
many
threads
accessing
the
same
memory
and
mutating
it
right,
and
this
is
the
kind
of
the
definition
of
a
data
race.
You
have
to
have
these
three
ingredients
more
than
one
thread
accessing
the
same
memory.
That's
the
sharing.
One
of
those
threads
at
least
has
to
be
mutating,
it
that's
the
mutation
and
they
have
to
not
be
ordered
with
respect
to
one
another.
B
So
no
locks,
no
condition
variables
and
usually
the
way
you
can
eliminate
data
races
most
easily,
then,
is
just
take
one
of
these
three
things
out.
All
right.
You
could
take
away.
You
could
go
to
sequential
programming
and
say
everything
is
ordered,
but
that's
kind
of
not
so
good.
It's
not
what
we
wanted.
You
could.
B
And
you
have
up
with
a
functional
language
which
has
a
lot
of
advantages,
but
also
some
performance
disadvantages
or
you
can
eliminate
all
sharing
and
that's
kind
of
this
actor
model.
I
was
talking
about
it
beginning
and
that's
great,
except
sometimes
you
do
need
to
coordinate.
Sometimes
you
have
your
shared
database
or
whatever
else,
and
these
values,
and
so
we'd
like
to
be
able
to
handle
those
cases
too
right.
B
So
what
we
try
and
rust
is
a
slightly
different
approach.
Instead
of
just
taking
one
of
these
ingredients
all
the
way
out,
we
say
we're
not
going
to
allow
you
to
have
sharing
a
mutation
at
the
same
time,
it's
okay
to
be
mutating
as
long
as
there's
only
one
reference
to
the
data
and
it's
okay
to
be
sharing
as
long
as
nobody's
changing
it.
The
problem
is
when
you
have
more
than
one
reference
and
those
references
are
being
changed.
That's
when
you
get
surprises
and
in
fact,
even
that's
a
little
too
strong.
B
A
B
A
mutex
you
want
to
have
a
lock,
you
want
to
have
some
locked
data,
that's
fine
as
long
as
you're
sure
and
guarantee
that
you
actually
use
the
lock
correctly
okay.
So,
let's
talk
about
the
sharing
a
mutation
thing,
the
way
that
we
prevent
you
from
doing,
sharing
and
nutation
at
the
same
time
is
through
the
system
called
ownership
and
borrowing.
The
idea
is
that
you'll
use
data
in
rust
in
kind
of
one
of
three
ways.
The
main
way
is
ownership.
B
This
is
sort
of
the
default
and
you're
familiar
with
ownership,
I
think
from
your
daily
life.
Probably
so,
if
you
have
like
a
book,
let's
say
that
you
owned
and
that
book
is
on
your
bookshelf.
That's
your
book!
Nobody
else
gets
to
use
it
and
if
they
want
to,
they
have
to
come.
Ask
you
permission,
but
one
of
the
things
you
can
do
with
this
book
is
you
can
give
it
to
a
friend
and
say:
hey,
happy
birthday,
here's
my
like
introduction
to
CS
or
whatever
books
you
own.
B
That's
my
bookshelf,
I,
don't
know,
and
at
that
point
it's
not
your
book
anymore
right.
It
belongs
to
this
friend.
They
can
do
whatever
they
want
with
it,
and
you
have
nothing
more
to
say:
that's
pretty
much
how
a
data
structure
works
in
rust,
so
here's
some
rust
code,
it's
the
first
we've
seen
so
I'll
explain
it
a
little
bit.
B
We
have
two
functions,
the
main
on
the
left
and
published
on
the
right
and
we're
creating
in
this
first
line,
where
the
arrow
is
we're,
making
a
local
variable
and
we're
what
we're
doing
is
we're
taking
a
vector
so
Veck,
nu
nu
is
not
a
keyword,
it's
just
a
method
in
rust,
but
it
creates
an
instance
of
a
type
by
convention
and
returns
it
so
we're
gonna
make
a
vector
and
store
it
in
the
local
variable
book.
And
so
what
we'll
end
up
with?
B
Is
this
now
like
and
C++
this
variable,
it's
fields
are
stored
on
the
stack
by
default,
so
this
will
be
stored
on
the
stack
and
you
notice,
I
declared
the
variable
as
immutable.
That's
what
the
mute
keyword
means
so
in
rust.
If
you
just
declare
a
local
variable
without
any
mute,
then
we
are
not
allowed
to
make
changes
to
it.
We
asked
you
to
highlight
the
places
where
you're
going
to
be
doing
mutation
that
helps
later
on
when
you're
reading
the
code
you
can
sort
of
see.
Oh
I
see
this
variable
is
being
incremented.
B
This
one
is
not
makes
it
easier,
and
in
this
case,
what
we're
going
to
do
the
mutations
we're
going
to
do
is
we're
gonna
push
on
to
the
vector.
That
means
we're.
Gonna,
add
things
at
the
end
right
and
this
works
just
like
a
vector
in
C++
or
Java.
You
have
some
backing
buffer,
it
gets
allocated,
it
goes
on
the
heap
it
gets
grows
when
it
gets
too
big.
That
sort
of
thing.
So,
in
this
case
let's
say
we're
pushing
strings,
then
we'll
have
two
strings.
The
fields
of
the
strings
are
laid
out
in
line.
B
B
Okay,
so
next
thing
I'm
going
to
do
is
call
this
publish
function,
and
this
is
where
things
start
to
be
a
little
more
different
than
what
you
might
expect
because
publish
takes
as
its
argument.
A
Veck
of
string
alright
and
what
that
means
in
rust
is
that
publish
takes
ownership
of
a
vector
of
strings
so
like
just
like
when
I
gave
the
book
to
my
friend
when
I
give
the
book
to
publish
it's
no
longer
mine
anymore.
B
So,
what's
going
to
happen
at
runtime,
when
we
do
this,
this
function
call
and
we
give
ownership
of
the
book
away.
We're
gonna
copy
over
the
fields
that
were
on
the
stack
into
the
Cawley's
stack
frame.
Then
we're
just
gonna
kind
of
forget
about
our
own
copy,
as
if
we
don't
have
it
right
now.
The
colleague
can
execute
publish
and
it
owns
this
book.
B
So
when
it
starts
executing
it
knows
that
nobody
else
in
the
whole
program
has
access
to
this
book,
but
it
but
itself
right
only
through
this
local
variable
can
do
whatever
it
wants
and
when
it
returns
at
that
point,
nobody
else
has
access
to
the
book.
Publish
is
done
using
it,
so
we
just
free
it
run
the
destructor
and
free
all
the
memory.
So
basically,
when
a
function
returns,
anything
that
it
owns,
which
it
hasn't
already
given
away,
gets
dropped.
That's
what
we
call
it.
A
B
B
When
you
create
a
value,
it's
yours
when
you
give
it
away
it's
theirs
and
the
last
one
freeze
it
and
don't
just
to
kind
of
drill.
This
in
I
want
to
emphasize
how
different
this
model
is
from
a
garbage
collected
by
by
default
model
right.
So
this
is
some
Java
code,
it's
kind
of
equivalent
I'm,
not
really
picking
on
Java
in
particular.
B
B
There
we
go
so
my
point
is
not
so
much
the
garbage
collectors
are
slow,
but
that
just
looking
at
these
signatures
actually
there's
a
lot
of
information.
Not
there
all
right.
If
you
just
look
at
the
signature
of
publish,
you,
don't
know
what
it's
gonna
do
with
that
vector.
You
don't
know
if
it
needs
that
vector
to
be
immutable
while
it
executes
soar.
If
it's
okay,
if
it's
being
mutated,
say
by
another
thread,
you
don't
know.
B
If
it's
going
to
start
a
thread,
you
have
to
read
and
understand
the
whole
set
of
code
before
you
can
know
these
interactions
and
that's
really
problematic.
Okay,
so
so
that
was
ownership.
Now
ownership
is
great,
but
it's
not
a
lot
of
times
like
if
I
give
a
book
to
my
friend,
I'm
I
might
be
giving
it
to
them
as
a
present,
but
I
might
also
be
saying
hey.
Why
don't
you
just
leave
through
this
book?
B
Read
a
couple
chapters
and
then
give
it
back
to
me
when
you're
done
and
it
works
the
same
way
with
data
structures
a
lot
of
times.
What
we
want
to
do
is
more
like
sharing,
and
so
for
that
in
rust.
We
call
that
borrowing
and
we
have
two
different
versions
of
it:
the
most
common
one
is
this
shared
reference
that
we're
going
to
see.
B
First,
where
you
can
have
many
different
copies
that
all
access
the
same
memory,
but
none
of
them
are
able
to
mutate
it
so
there's
our
example
and
I'm
gonna
make
a
vector
here.
This
is
all
the
same
as
the
first
example.
Basically,
but
when
I
call
this
use
function,
we
see
that
the
type
of
the
vector
on
use
is
not
Veck
of
entir,
it's
ampersand
Veck.
So
that
means
it's
taking
a
reference
to
a
vector
in
sort
of
operational
terms,
but
but
in
a
higher
level,
its
borrowing,
the
vector
from
its
caller.
B
It's
just
going
to
temporarily
make
use
of
it.
It
doesn't
need
ownership
and
on
the
other
side
we
don't
call
Veck
by
by
value.
We
give.
We
use
this
ampersand
expression
to
say
we're
gonna,
lend
out
the
vector
and
give
it
to
use.
So
at
runtime
that's
going
to
make
a
pointer
and
the
function
use
can
run
along
and
it
can
read
and
do
whatever
needs
to
do
from
this
vector
and
when
it's
done
nothing
gets
freed.
B
B
So
we
saw
now
that
how
you
can
pass
references
around,
but
what
I
want
to
drill
into
a
little
more,
is
how
this
immutability
part
works.
So
the
thing
is
the
immutability
and
rust
is
not
binary.
It's
not
on
or
off
all
the
time
it's
more
like,
depending
on
where
in
the
program
you
are,
is
whether
or
not
you
can
determine
whether
or
not
you
can
mutate
a
variable.
B
So
when
we
start,
we
have
this
variable
book
and
we
declared
it
as
mutable,
and
that
means
that
initially
we
own
it,
no
one
else
has
access
to
it.
We're
free
to
mutate
it
right,
so
we
can.
For
example,
here
we
saw
we
can
call
push
that's
okay,
but
at
some
point,
when
we
do
this
borrowing,
when
we
have
one
of
these
ampersand
expressions
now
we
start
to
borrow
the
book
and
what
we'll
do
then
is
we'll
look
and
see
what
part
of
the
code
uses
this
reference
right.
B
So
it
basically
extends
from
the
point
where
you
borrow
it
to
the
last
place
where
that
reference
might
be
used
and
in
some
cases
the
reference
might
get
copied
into
other
variables
or
something.
But
here
it's
relatively
simple,
the
last
place
that
R
is
used
and
I
should
add.
This
is
actually
using
an
if
you,
the.
B
Compile
there's
a
little
stricter
than
this
same
basic
idea.
This
is
the
new
version
that
we're
gonna
be
releasing
soon
with
some
of
the
newer,
more
ergonomic
features
that
I'm
showing
you
here,
but
it's
the
same
ideas,
and
so
during
this
period
of
time,
while
this
reference
is
in
use,
we
now
actually
have
sharing.
We
have
two
different
ways
to
name
the
same
data.
B
We
can
go
through
the
original
variable
book
or
we
can
go
through
this
reference
R
and
they
both
access,
the
same
underlying
vector
and
so
for
that
reason
we're
not
going
to
allow
mutation
right.
So
it's
okay
to
call
like
book
Len
that
just
reads
the
the
vector
that
doesn't
mutate
anything
that's
allowed,
but
if
we
try
to
call
push
whether
it
be
through
the
original
variable
book
or
through
the
reference
that
is
going
to
create
an
error
right
and
the
compiler
won't
allow
it.
B
But
afterwards,
once
the
sharing
is
done,
the
variable
returns
to
its
original
state
and
we
can
mutate
it
if
we
like.
So
you
have
this
notion
of
time.
Basically,
where
in
the
program
are
you
is
the
variable
borrowed
at
this
point?
If
so,
you
can't
mutate
it
all
right.
So
that's
shared
references
and
then
I'll
cover
the
last
point,
which
is
mutable
references.
So
this
is
the
same
basic
idea.
B
You
want
to
temporarily
give
access
to
your
data
structure,
but
you
want
to
allow
the
the
function
you're,
calling
or
whatever
to
make
changes
to
the
data
structure
right.
So
we
have
a
function
like
edit.
That's
going
to
change
the
book
in
some
way
and
it
kind
of
looks
the
same
syntactically
instead
of
ampersand
back,
we
have
ampersand
mute
Veck
to
make
the
mutation
explicit,
but
otherwise
it's
kind
of
a
very
similar
right
and
in
fact,
at
runtime
it's
identical
we're
going
to
pass
a
pointer,
that's
all,
but
what
it
happens.
B
Semantically
is
a
little
different,
we'll
make
this
reference,
but
the
original
variable
book
instead
of
making
it
read-only
we're
gonna,
make
it
completely
inaccessible.
You
can't
access
it
for
any
reason
until
the
sharing
is
done.
So
if
we
go
back
to
well
okay,
so
then
the
edit
function
can
execute
and
read
the
book.
Now.
If
we
go
back
to
this
to
this,
this
kind
of
similar
example
here
I've
got
the
different
lines
of
code,
we'll
see
how
it
plays
out
right.
B
So
the
variable
book
starts
out
as
mutable
same
as
before,
but
when
I
make
the
shared
borrow
right
here
we
will
again
analyze.
How
long
is
this
reference
in
use
and
in
that
period
we're
just
not
going
to
allow
access
to
the
book
variable
so
here
the
book
variable.
If
we
try
to
use
it,
we'll
just
get
an
error,
even
if
all
we're
doing
is
reading
from
it
right-
and
this
will
be
important
for
parallel
access
later,
but
we
can
use
this.
B
Reference
are
to
do
mutations
or
reads
as
we
choose
and
afterwards
once
the
the
the
sharing
is
done.
We
can
do
whatever
we
want
through
the
book
right,
we're
completely
free.
It's
it's
accessible
like
before
all
right.
So
that's
ownership
and
borrowing.
That's
the
three
patterns
of
rust,
but
I
wanted
to
show
you
just
two
other
minor
things
which
kind
of
elaborate
this
idea
and
show
you
how
they
play
out
because
you'll
need
it
to
see
the
examples
of
parallel
programming
later
the
first
one
is
what
closures
a
little
bit
about
closures
in
rust.
B
So
a
closure
is
a
callback.
It's
a
function.
It's
basically
a
function
that
you
define
locally,
which
is
allowed
to
reference
the
local
variables
from
its
environment
and
do
things
with
them
right
and
one
of
the
things
you
can
sometimes
do
is
modify
them.
So
here's
an
example
where
we
have
a
counter,
which
is
an
integer
variable,
it'll,
be
stored
on
our
stack
and
we're
gonna
make
a
closure.
That's
here,
that's
gonna
increment
that
counter
every
time
you
call
it
so
in
rust,
a
closure
is
indicated
by
these.
B
These
pipes
in
between
them
usually
goes
a
list
of
arguments.
In
this
case
we
don't
have
any
arguments,
it's
kind
of
like
Ruby
sort
of,
and
the
key
idea
is
it's
gonna
access
and
increment.
This
counter
in
the
parents
stack
frame
right
directly
where
it's
stored,
so
in
a
way
it's
actually
borrowing.
The
counter
has
a
mutable
reference
inside.
That's
how
we
implement
it
to
the
counter
on
the
parent
stack
frame,
so
in
the
same
way
that
when
you
did
a
mutable
borrow,
we
looked
and
saw.
B
B
It
also
helps
to
make
the
code
readable
if
you've
ever
tried
to
read
a
really
long
program
with
no
type
annotations
anywhere.
It
can
be
a
little
confusing,
and
so
we
do
the
same.
We
ask
you
to
annotate
your
borrowing
patterns
in
the
same
way
in
function,
signatures
so
now
I'm
showing
you
a
little
more
rust
here.
This
is
actually
defining
a
method.
It's
a
method,
it's
in
the
standard
library.
So
let
me
walk
you
through
it.
B
The
first
part
is
this
keyword,
imple
that
stands
for
implement
and
it's
a
way
to
add
methods
to
types.
So
here
we're
implementing
a
methods
and
the
type
we're
implementing
them
on
is
this
bracket
T
bracket,
which
is
an
array
we're
basically
saying
some
number
of
T's
in
memory
adjacent
in
memory.
It's
a
bounced
check,
ray
I
should
say,
or
we
call
it
a
slice
so-
and
this
is
the
name
of
the
method
split
at
mute
and
what
this
method
does
is
it
takes
in
a
slice?
B
That's
the
self
takes
an
immutable
reference
to
a
slice
really,
which
means
that
it
has
like
a
kind
of
reference
to
the
start
and
a
length,
and
you
can
access
any
of
the
things
in
the
array
and
it
takes
a
midpoint
which
is
an
integer
and
it
divides
the
slice
in
two
and
gives
you
back
two
sub
slices
before
and
after
the
midpoint.
So
I'll
show
you
by
example.
This
is
a
caller.
This
is
an
example
of
calling
that
method
right
here
and
you
see
that
we're
calling
it
on
Veck
with
this
midpoint
of
three.
B
So
when
you
have
when
you're
returning
references
out
of
a
function,
you
can
essentially
tag
with
this
today
where
they
came
from
and
in
fact
this
annotation
wouldn't
be
required.
We
have
defaulting
rules
that
would
cover
this
case,
but
to
make
it
clearer,
I
wrote
them
in.
So
what
it's
saying
is
these
two
slices
that
I
returned
were
borrowed
from
the
input
slice?
They
alias
they
kind
of
share
with
same
memory
as
the
input
slice.
So
that
means,
while
you
have
access
to
those
two
slices,
you
have
to
consider
the
input
slice
to
be
borrowed.
B
So,
while
we're
using
less
and
greater
in
this
code,
we
can't
use
the
original
Veck
once
we're
done.
We
can
use
it
again
same
idea,
all
right,
so
you've
just
learned
rust
or
this
subset
of
rust
that
I'm
going
to
teach
to
you
today.
But
those
are
the
key
ideas
of
these,
of
these
ownership
and
borrowing
and
and
basically
this
pattern
just
plays
out
across
across
rest
code,
but
what's
really
interesting
about
it-
is
what
we
can
do
with
it
and,
in
particular
the
parallel
abstractions
that
we
can
handle.
B
So
the
basic
thing
that
we
observed,
if
you
have
shared
memory
and
shared
mutable
state,
it's
a
really
great
foundation
for
implementing
parallel
abstractions,
that's
kind
of
in
a
sense,
the
easy
part,
but
what
it
is
not
very
good
at
is
ensuring
that
people
use
them
correctly
right.
You
can
give
people
a
wonderful
API
that
makes
parallel
programming
really
easy
as
long
as
they
use
it
right,
but
if
they
make
even
the
slightest
mistake,
they
get
into
trouble,
and
so
this
is
an
example
from
go
I'm
not
really
picking
on
go.
B
So
here's
what's
happening,
I'm,
sending
I'm,
making
a
mutable
map
and
I'm
sending
it
over
a
channel
and
what
happens
is
I'm
supposed
to
stop
using
the
map
at
this
point,
I
just
sent
it
to
another,
go
routine.
The
other
girl
routine
is
supposed
to
read
it
and
do
whatever
it
wants
with
it.
And
I
am
supposed
to
do,
is
just
forget
about
it,
but
there's
nothing
that
actually
stops
me
from
doing
that.
B
Right
and
I
think
the
go
answer
here
is
to
run
a
dynamic
data
race
detector,
which
I'm
sure
would
certainly,
in
this
case,
trivially,
find
this
example,
but
in
general,
dynamic
testing.
You
know
it's
a
good
solution,
but
it
also
requires
you
to
have
a
comprehensive
test,
suite
and
so
forth
and
seems
less
good
than
if
you
can
guarantee
statically
that
you
don't
have
the
problem
right.
So
what
we
do
in
rust
is
a
little
bit
different.
This
is
the
same
code
translated.
It
creates
a
hash
map
inserts
it.
It
sends
it
over
the
channel.
B
But
when
you
look
at
the
definition
of
the
channel,
here's
the
send
method
on
channels
you
see.
First
of
all,
this
is
a
method.
It's
defined
generically
over
a
channel
of
some
type
T,
that's
the
kind
of
data
that
goes
over
the
channel
and
the
key
part
is
here.
This
parameter
is
going
to
take
ownership
of
that
data
all
right.
B
So
if
you
have
ownership
message,
passing
at
least
is
kind
of
very
nicely
expressed
all
right,
but
we
can
go
a
little
bit
further
and
we
can
do
some
other
kind
of
patterns
as
well,
and
these
are
going
to
leverage
the
ownership
and
borrowing
system
to
make
these
different
API
safe.
So
locking
is
a
good
example.
A
lock
is
a
kind
of
it's
not
hard
to
know
how
to
use
a
lock
in
the
abstract.
If
someone
tells
you,
okay,
you
have
a
lock
any
time.
You
touch
this
data,
you
have
to
acquire
the
lock.
B
It
sounds
easy,
but
it's
very
easy
to
forget
to
acquire
the
lock
or
it's
pretty
easy
to
release
it.
A
little
too
early
before
you
were
really
done,
and
so
what
we
do
in
rust
is
we
use
ownership
and
borrowing
to
make
sure
that
doesn't
happen
right.
So
we
have
a
type
called
mutex
and
the
key
idea
is:
this
is
not
just
a
lock
by
itself.
It's
a
lock
paired
together
with
the
data
that
it
protects.
So
in
this
case
it's
an
integer.
B
So
what
we'd
have
here
is
a
mutex
with
a
shared
reference
over
to
this
lock
and
inside
the
lock
is
this
data,
and
the
idea
is
because
the
lock
owns
the
data
nobody
can
get
to
that
data
without
going
through
the
API.
Is
that
the
mutex
or
the
lock
offers,
and
really
it
only
offers
one
method
which
is
called
lock
and
with
that
method
does?
B
Is
it
acquires
the
lock
first
of
all
so
that'll
block
until
all
the
other
threads
have
or
until
you
have
unique
access,
and
then
it
returns
a
guard
and
a
guard
is
kind
of
as
another
part
of
the
mutex
API.
It
overloads
the
duf
operator
and
rusts
terms,
but
it
kind
of
acts
like
a
pointer.
So
it
has
a
pointer
directly
into
this
memory
and
it
lets
you
access
it.
B
What
happens
is
it
has
the
side
effect
of
releasing
this
luck
and
letting
people
access
it
right?
So
yeah,
it's
kind
of
a
nice
setup,
because
if
you
try
to
use
you
can't
get
access
to
the
data
without
getting
the
lock
and
once
you
have
access
to
the
data
you
keep
it
until
you're
done
using
it
at
which
point
it
naturally
gets
freed.
So
this
is
an
example
of
using
ownership
and
borrowing
to
manage
other
kinds
of
resources
in
a
sense.
B
In
this
sense,
the
resource
is
the
lock
state,
but
the
same
techniques
that
manage
memory,
the
destructors
that
free
memory
also
can
be
used
here
all
right,
so
that's
locking
the
last
one
I'm
going
to
show
you
is
fork/join,
which
is
a
way
to
kind
of
divide
up
data
and
access
it.
It's
kind
of
data
people
call
it
data
parallelism,
sometimes
but
divide
up
data
into
discrete
parts
and
process
those
parts
independently.
B
So
there's
nothing
in
the
rust
standard
library
that
supports
that
style
of
programming.
But
there
are
third-party
packages
that
do
this
is
one
called
rayon
which
I
wrote
the
first
version
of,
but
now
it's
maintained
by
a
lot
of
people
and
it
basically
it
consists
of
a
bunch
of
API
is.
But
this
is
the
core
one,
the
most
simple
one:
it's
basically
a
method
called
join
that
takes
two
closures
and
what
it
does
is
conceptually
anyway.
It
starts
two
threads,
execute
those
closures
and
waits
for
them
to
finish,
and
then
it
returns.
B
So
you
kind
of
have
this
execution
like
a
diamond
shape,
and
this
is
really
handy
for
sort
of
divide
and
conquer
style.
Things
where
you
want
to
take
some
big
set
of
data
divided
up
into
little
parts
process
them
recursively
down
the
line,
all
right,
so
something
like
queue.
Sort,
if
you
don't
remember
queue,
sort,
it's
not
that
important,
but
this
is
sort
of
a
queue
sort,
implementation
and
the
way
it
works.
It
takes
in
a
mutable
reference
to
some
data,
all
right.
So
we
saw
these
before.
B
This
is
a
slice
and
the
key
point
is
when
Q
sort
starts
executing.
It
doesn't
own
the
slice,
but
it
still
has
unique
access
to
it.
Nobody
else
can
be
accessing
this
slice.
While
you
sort
execute,
then
it
picks
a
pivot
and
does
the
partition
like
I,
said,
if
you
don't
remember
how
Q
so
it
works
not
so
important.
B
It
would
be
nice
if
we
could
do
this
in
parallel
and
that's
exactly
what
rayon
Johanne
lets
us
do
right.
So
we
can
call
join
like
so
and
now
we
process
the
less
and
the
greater
halves
in
parallel
with
one
another
and
wait
for
them
to
finish
and
the
the
type
checker
is
pretty
happy,
because
each
of
these
closures
is
referencing,
a
different
variable
where
one
is
referencing
less
and
one
is
referencing
greater
and
in
this
case
it's
a
mutable
reference.
They
have
to
be
different
all
right.
B
So
this
is
another
example
where
these
kind
of
api's
are
in
a
lot
of
languages.
Java
has
awesome.
Foreign
pool,
Scala
has
great
parallel,
iterators
and
so
forth,
but
they
all
could
be
misused
right.
It
would
be
possible
to,
for
example,
accidentally
use
the
same
slice
and
both
halves
and
every
time
I
put
this
up.
I
think
that
is
the
most
artificial
bug.
B
Nobody
would
do
that,
but
in
fact
I've
made
this
bug
like
a
number
of
times
since
I
made
this
slide,
it's
really
easy
to
do
when
your
copy
and
pasting
and
so
on,
and
of
course,
if
we
try
to
do
that
in
rust,
we
get
a
compilation
error,
because
we
only
allow
one
mutable
reference
at
a
time.
Each
of
these
closures
is
now
taking
a
mutable
reference
to
the
same
variable,
yeah.
B
A
B
That's
a
good
question:
the
answer
is:
we're
trusting
it.
I'm
gonna
show
you
how
how
that
works
out,
but
yeah.
We
don't
that
particular
function.
We
do
trust,
but
it
is
part
of
the
standard
library.
The
basic
assumption
is:
whenever
you
have
two
variables
that
are
both
accessible
at
the
same
time,
they
must
be
disjoint
and
the
RUS
type
system
guarantees
that
we'll
see
you
later.
You
have
escape
hatches
that
let
you
write
things
that
it
wouldn't
allow,
and
if
you
fail
to
uphold
that
guarantee,
then
yes,
that's
a
problem.
B
So
using
that
we've
seen
fork/join,
there's
a
whole
lot
of
cool
other
things
you
can
do
I
mean
it's
not
that
surprising.
In
a
sense,
we
offer
basically
threads
a
mutable
state,
which
is
the
building
blocks
for
all
these
different
kinds
of
abstractions,
and
it's
nice
to
so.
You
can
see
how
they
all
play
out
with
ownership
and
borrowing
if
you
dig
in
so
getting
at
exactly
this
other
question,
though,
what
about
split
up
mutes
and
how
does
that
work?
So
rust?
B
Has
this
notion
of
unsafe,
rust
right
and
our
vision
here
is
that
we
wanted
to
have
an
extensible
language.
We
want
to
have
a
language
with
a
relatively
simple
core
that
lets.
You
write
libraries
that
do
any
crazy
thing
that
you
could
imagine
right
and
there's
lots
of
stuff
that
ownership
and
borrowing
can't
directly
express.
B
All
these
things
are
kind
of
outside
of
the
core
language,
and
what
we
want
to
do
is
allow
you
to
write
that
code,
much
as
you
would
in
C
and
C++,
but
at
the
API
boundary
use
ownership
and
borrowing
to
guarantee
that
your
callers
are
not
misusing
it
right,
and
so
the
core
idea
is:
this
is
a
safe.
We
call
a
safe
abstraction,
so
we
had
this
keyword
unsafe.
B
It
basically
says:
hey
trust
me,
I
got
this,
you
know,
and
it
gives
you
access
to
a
couple
of
extra
features
that
you
don't
normally
get
to
use
in
rust,
a
sort
of
superset
of
rust,
which
is
effectively
C
in
rust
index.
You
get
raw
pointers
in
particular,
and
the
idea
isn't
that
you
like
sprinkle
this
wherever
you're
having
a
problem,
you
just
turn
off
the
safety
checks.
The
idea
is
that
you
write
a
boundary
around
it,
that
it
has
a
safe
interface
right
and
I.
B
Think
I
would
say
pretty
much.
Every
language
has
this
escape
hatch
somewhere.
Sometimes
they
call
it
an
F
fi
where
they
call
C
code,
but
it
happens
at
some
point
right.
You
have
to
have
some
place
where
you
kind
of
drop
down
to
the
next
level.
Even
C
has
inline
assembly
right,
and
we
have
that
too,
but
not
surprisingly,
and
so
so
we
have
it
here
and
by
putting
it
in
the
language
that
has
this
convenience
that
you
can
actually
write
things.
B
You
know
in
rust
all
the
way
down,
like
that's
key
to
being
a
plausible
replacement
for
C
I
would
say
so.
You
might
be
curious
how
much
unsafe
code
happens
in
practice.
I
know
I
was,
and
the
answer
is
really.
It
depends
on
what
you're
doing
a
lot
of
programs
none
at
all,
but
some
have
more
so
this.
This
is
a
little
mini
study.
We
did
I'm
going
to
talk
in
more
detail
about
it,
but
we
were
looking
at
this
parallel
CSS
renderer
that
we
used
that
we
implemented
it's
now.
B
Shipping
in
Firefox
and
I
want
to
know
how
much
unsafe
code
was
in
there,
and
the
first
measurement
we
took
I
have
to
say
was
a
little
little
distressing
to
me
because
it
was
35%
measured
in
terms
of
lines
of
code
and
I
thought
that
is
way
too
high.
That's
ridiculous!
It
turns
out
that
if
you
look
at
the
code,
it's
actually
you
can
kind
of
split
it
into
two
parts.
B
First,
there's
the
real
code,
the
interesting
stuff
and
then
there's
all
these
auto-generated
FFI
bindings,
because
as
I'm
going
to
talk
about
an
event,
this
Russ
code
interacts
with
a
bunch
of
C++
code
and
shares
data
structures
with
them,
and
these
these
bindings
we're
pretty
sure
they're
correct.
They
get
auto-generated.
B
B
So
there's
nothing
wrong
with
unsafe
code
right
they
it's
it's
a
key
part
of
rust
in
our
mind
because
we
want
it
helps,
keep,
though
the
rest
of
the
language
simple,
but
it
should
be
used
well
and
judiciously.
Let's
say
so
along
those
lines:
I
wanted
to
spend
a
little
time
talking
about
how
rust
can
be
used
in
practice
and
what
it's
like.
Our
experience
is
using
it
in
Firefox
and
what
we
did
with
rust
here.
B
So
we've
been
Oh
from
the
beginning
in
developing
rust,
we've
had
this,
we
have
Mozilla
have
also
been
working
on
another
project
called
servo,
which
is
the
kind
of
reimplementation
of
the
browser
from
the
ground
up
imagining
what
it's
like.
What
would
we
do
if
we
were
going
to
do
layout
in
parallel?
How
would
it
work
and
so
on,
and
what
servo
managed
to
do
is
take
just
a
little
piece
of
that
and
deploy
it
now
in
Firefox
itself
right
and
the
key
part
that
we
did
was
called
a
CSS
styling.
B
So
if
you're
familiar
with
HTML
or
if
you're,
not
I,
should
say
basically
the
way
your
websites
work,
is
you
have
this
Dom,
which
is
a
tree
saying
like
here's,
a
paragraph
of
text,
there's
an
image
and
so
forth,
and
they
have
a
bunch
of
properties
like
what
color
is
it?
Where
is
it
on
the
screen
and
these
properties
get
computed
via
a
set
of
rules
called
CSS,
and
the
important
part
of
this
is
that
for
any
given
node
the
rules
that
apply
just
depend
on
its
ancestors.
B
So
if
you
have
a
single
node,
you
can
trivially
process
all
of
its
children
in
parallel,
they
should
have.
They
should
be
independent
from
one
another,
so
this
is
sort
of
embarrassingly
parallel
and
this
is
not
escape
notice.
If
you
look,
there's
a
bugzilla
bug
reported
seven
years
ago,
saying
hey,
let's
paralyze
this,
that
would
be
cool,
and
if
you
read
the
history
of
this
bug,
you'll
see
that
they
tried
I
think
twice,
but
at
least
once
pretty
hard
and
failed
right
and
I
talked
to
the
people
who
did
it?
It's
not
that
it's
impossible.
B
It's
definitely
possible.
It's
just
that.
Getting
all
the
data
races
out
was
a
real
challenge
and
as
fast
as
they
could
pull
them
out,
other
patches
would
land
that
would
put
new
ones
back
in
so
keeping
the
data
races
out
was
also
a
challenge
plus
they
hit
some
annoying
problems
around
C++
and
Windows
and
so
forth.
Rust
has
a
pretty
good
cross-platform
story,
I
should
point
out
here,
and
so
basically
it
was
an
example
of
something
we
wanted
to
do.
B
We
had
a
team
full
of
really
good
sleep,
us
plus
people
trying
to
do
it
and
they
couldn't
do
it
right,
and
so
we
get
back
to
popeye
here.
So
when
you
change
the
equation
and
you
have
the
ability
to
use
a
language
that
does
these
safety
checks,
the
results
were
different
right
in
rust.
They
were
able
to
make
it
work
and
in
such
a
way
that,
if
future
patches
land
they
violate
the
safety
guarantees,
then
the
build
breaks,
and
so
somebody
notices,
so
that's
pretty
cool
it
works.
B
Unfortunately,
I
don't
have
a
lot
of
measurements.
I'm
keep
bugging
the
team
to
send
me
more.
These
are
the
ones
I.
Have
it
they're,
pretty
good
in
a
sense.
So
what
I
have
to
explain
is
that
these
are
measurements
from
the
moment
the
browser
starts
executing
until
you
see
stuff
on
your
screen,
and
it
includes
a
lot
of
things
and
only
a
little
part
of
that
is
the
page
layout,
and
only
a
part
of
that
page
layout
is
the
CSS
styling.
B
So
the
part
we
actually
optimized
right,
but
you
can
see
that
there
was
nonetheless
a
pretty
dramatic
effect
for
some
pages
other
pages,
not
as
much
but
but
definitely
a
big
win,
especially
in
browser
terms
where
it's
pretty
hard
to
score
score
improvements
on
these
pipelines.
So
the
other
part
of
this
story
that
I
think
is
really
cool.
Is
that
in
terms
of
the
whole
browser
engine,
we
ported
the
CSS
styling
into
rust
and
we're
doing
another
part
now
that'll
land
in
a
little
while
called
web
render.
B
But
all
the
other
code
stayed
in
C,
pile
plus
that's
what
all
this
FFI
code
came
from.
So
that
means
you
don't
have
to
adopt.
If
you
want
to
Russ,
it
doesn't
have
to
be
I'm
gonna,
rewrite
all
my
code
and
have
a
flag
day
where
we
like
convert
everything
to
rust.
All
at
once.
That's
not
very
practical!
You
can
do
it
piecemeal,
a
piece
at
a
time
and
compile
a
rust
to
it,
to
a
library
that
links
in
with
the
rest
of
your
code,
whether
it's
in
C++
or
something
else.
B
All
right
so
I've
kind
of
given
you
the
hard
sell
I,
would
say
on
the
rust
type
system.
What
I
think
it
has
to
offer
and
all
that
stuff
and
I
want
to
step
back
a
little
bit
and
talk
about
the
rust
project
kind
of
as
an
open
source
project,
how
we
do
our
governance,
how
you
could
get
involved.
The
first
thing
is
rust:
we've
tried
from
from
the
beginning
to
be
a
kind
of
independent
open-source
project
that
is
governed
independently
by
its
users
right.
B
So
we
have
a
leadership
structure
where
we
have
a
lot
of
sub
teams.
All
the
official
decisions
are
made
by
these
sub
teams
like
what
language
features
to
add
what
to
prioritize
and
right
now
there
are
about
sixty
people
involved.
There's
some
overlap
between
teams,
so
the
numbers
don't
quite
add
up,
but
of
those
only
ten
of
them
are
employed
by
Mozilla.
So
we're
not
it's
not
a
matter
of
Mozilla
kind
of
completely
controlling
this
endeavor
and
we
would
like
to
see
more
companies
getting
heavily
involved.
B
We
have
a
nightly
compiler
which
allows
access
to
all
the
features
of
rust,
including
ones
that
were
not
sure
about
it,
gets
built
every
night,
it's
kind
of
like
a
browser
pipeline,
and
you
use
that
one.
You
get
to
use
everything
but
you're
taking
on.
If
you
use
those
new
features
that
are
not
stable,
you're
taking
on
a
certain
measure
of
risk
that
they
may
change,
and
you
may
have
to
re-up
recompile
your
code
and
fix
it,
but
you
also
can
give
us
feedback
right
and
control
the
direction
of
those
features.
B
And
if
that's
not
acceptable
to
you,
we
have
a
stable
release
that
comes
out
every
six
weeks.
It
contains
only
those
features
that
we
we
are
willing
to
commit
to
and
that
will
continue
working
forevermore
in
terms
of
designing
new
features.
We
do
that
all
through
this
RFC
process,
so
people
can
come
either
internal
to
the
team
or
from
outside
and
suggest
a
feature
by
writing
up
an
RFC,
and
then
you
know
it
will
get.
B
There
will
be
a
lot
of
comments
and
back
and
forth
and
eventually
will
either
accept
it
or
not,
at
which
point
we
start
moving
to
the
implementation
phase,
and
these
I
chose
these
ones,
which
were
written
by
Josh
Triplett,
who
works
at
Intel
and
is
he's
now
part
of
the
laying
team
in
some
roles,
but
initially
when
he
wrote
especially
the
first
RFC.
He
wasn't
right.
B
This
was
a
feature
that
came
from
the
outside
and
that
seemed
like
a
good
idea
to
add
unions
if
ever
F
or
F
F
I
with
C,
and
we
worked
through
it
that
way.
So
these
features
come
kind
of
the
important
thing
I
want
to
emphasize
is
everybody
goes
through
the
RC
process,
whether
they
are
internal
to
the
team
or
not,
and
it's
it's
been
a
really
good
thing
for
the
product.
I
would
say
well
for
rust,
so
stepping
up
one
higher
level.
We
also
have
this
roadmap
process.
B
So
in
terms
of
where
we
are
FCS
decide
about
a
particular
feature,
but
our
roadmap
process
is
kind
of
every
year
and
we're
about
to
start
for
2019
coming
or
18
coming
up,
we
kind
of
set.
What
are
we
gonna?
What
are
the
overarching
themes
that
we're
going
to
be
working
on
this
year
and
that
kind
of
determines
which
are
FCS
were
most
likely
to
accept
if
they
fit
into
those
roadmap
goals
or
not
all
right,
so
I
hope
I've.
Given
you
a
taste
for
rust,
I
think
I.
B
Think
rust
is
a
pretty
exciting
thing,
obviously,
because
I
work
on
it,
but
if
you're
interested
in
rust,
you
should
come
and
talk
to
me
or
you
can
check
out
one
of
these
books,
so
Riley
book
I
think
is
actually
available.
Now
I
think
I
saw
something
about
just
in
the
last
few
days.
It
started
to
ship,
but
there's
also
a
book
on
our
website.