►
From YouTube: C++Now 2017: Niko Matsakis "Rust: Hack Without Fear!"
Description
http://cppnow.org
—
Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/boostcon/cppnow_presentations_2017
—
Through the concept of zero-cost abstractions, C++ has shown that it is possible to combine low-level control with high-level programming concepts. Rust is language that aims to offer the same sorts of zero-cost abstractions that C++ is capable of, while also enforcing memory safety and data-race freedom. The secret sauce is Rust's core notion of "ownership", which enables:
- Memory safety without garbage collection;
- Concurrency without data races,
- Abstraction without overhead.
In this talk, I'll explain ownership and show how Rust uses it to guarantee thread safety, amongst other things. I'll also talk about how Rust is designed to scale to large code-bases, sharing some of our experiences here at Mozilla from integrating Rust code into Firefox.
One final theme of the talk is that the benefits of ownership go beyond having fewer bugs: once you are freed from the need to prevent memory-safety violations, it becomes possible to write -- and **maintain** -- programs that aggressively pursue parallelization and other kinds of optimizations that would have been too risky or too difficult before.
—
Nicholas Matsakis is a senior researcher at Mozilla research and a member of the Rust core team. He has been working on Rust for nearly six years and did much of the initial work on its type system and other core features. Prior to working on Rust, he did his undergraduate studies at MIT and completed a PhD at ETH Zurich in 2011. He also spent several years at DataPower Technology, a startup since acquired by IBM, working on the JIT compiler and networking runtime.
—
Videos Filmed & Edited by Bash Films: http://www.BashFilms.com
---
*--*
---
A
So
today,
I'm
very
excited
to
announce
our
first
keynote
speaker.
Nico
misaki's
has
been
a
senior
researcher
at
Mozilla
and
a
core
member
of
the
rest
team
where
he
worked
on
the
initial.
A
lot
of
initial
work
on
the
type
system
on
other
important
features
for
been
working
on
rust
for
about
six
years.
Previously
he
did
his
undergrad
at
MIT
and
completed
a
PhD
at
ETH
Zurich
in
2011,
and
he
also
sent
us
some
years
at
data
power
technology
since
acquired
by
IBM,
where
he
worked
on
JIT
compiler
and
networking
runtime.
B
As
Jackie
just
said,
I
was
I've
been
working
on
rust
for
about
six
years,
but
what
she
didn't
mention,
which
because
I
didn't
tell
her
so
before
that
I
have
been
a
pretty
big
fan
of
C++
for
a
long
time.
I
just
need
to
remember
asking
my
parents,
for
this
book
must
have
been
middle
school
for
her
Christmas
present
and
I
pored
through
the
whole
thing.
B
I
couldn't
find
a
picture
of
me
reading
it,
though,
but
I
did
find
this
reading
the
Zen
of
graphics
programming
with
my
dad
at
some
point
or
another,
but
I
thought
was
pretty
cool
but
I'm
here
today
to
talk
about
rust
and
so
I
know.
Not.
Everybody
here
is
familiar
with
rust
or
even
heard
of
rust,
at
least
based
on
some
of
the
conversations
I
had
so
far.
So
I
thought
I'd
give
a
kind
of
really
quick
intro
to
what
rust
is
at
a
very
high
level,
and
so
the
basic
idea
is.
B
We
want
to
take
all
these
nice
safety
guarantees
that
you
can
get.
If
you
write
a
program
in
Java
or
C
sharp
or
some
other
language
like
that,
like
that
you're
not
going
to
have
double
fries
and
segmentation
faults,
in
fact,
we
want
to
go
further
and
say
you
also
won't
have
data
races,
so
your
curl
up
programs
are
way
more
predictable
and
have
a
type
system,
that's
more
expressive
that
can
help
you
get
correctness,
guarantees
or
not
guarantees,
but
good
correctness.
B
Beyond
these
basic
guarantees,
we
want
to
do
all
of
that
without
having
to
have
a
runtime
or
a
garbage,
collector
or
really
any
undo
performance
overhead,
so
I've
heard
be
honest:
two
scoops
a
to
C
Pascal
tries
to
leave
no
room
for
a
language
between
it
and
assembly.
Rust
kind
of
has
a
similar
ambition
right.
There
are
people,
writing
criminals
and
rust
and
so
forth,
so
I
think
overall.
Basically,
our
big
goal
is
that
we
want
to
have
productive
systems.
Programming
and
I
mean
productive
in
a
kind
of
global
sense.
So
how?
B
Basically,
how
fast
can
you
get
your
program
up
and
running?
How
fast
can
you
meet
your
performance
requirements,
but
also
how
fast
can
you
or
how?
Well,
can
you
maintain
it
over
time
right
because
that
can
be
a
big
productivity
drag
and
today
is
kind
of
a
good
day
to
do
a
talk
on
rust
because
it's
almost
our
two-year
oath
day
so
to
speak.
We
had
our
one-year
1.0
release.
Sorry,
two
years
ago,
May
15th
so
yesterday,
and
in
that
time
rust
has
been
growing.
We've
got
a
lot
of
people
using
it
in
production.
B
Now,
I
have
a
partial
list
here
of
the
most
kind
of
biggest
names,
but
you
can
see
a
more
complete
list
on
our
web
page.
So
of
course,
Firefox
has
started
to
integrate
it
and
I
say,
of
course,
because
Mozilla
sponsored
rust,
but
actually
it
wasn't
a
given
that
it
would
a
succeed
or
B
make
it
into
Firefox.
We
had
to
kind
of
prove
our
way
there
as
well
and
Dropbox
has
been
using
it
under
servers
and
recently
also
on
client
side.
B
Npm
is
integrated,
it
gnome
hasn't
actually
put
anything
into
production,
but
we've
been
working
a
lot
with
the
gnome
team
and
we're
kind
of
excited
to
see
where
that
might
go.
There
are
some
gnome
libraries
starting
to
experiment
with
rust,
so
in
honor
of
rust
being
two
years
old,
though
I
thought
I
would
start
with
something.
Two-Year-Olds
love
which
is
I
would
tell
you
a
story.
B
B
The
key
thing
is,
we
don't
need
the
result
until
the
very
end
from
this
data
structure.
So
this
is
what
gives
her
an
idea
she
says.
I
could
probably
make
this
go
faster.
If
I
introduced
another
thread
right,
I
could
have
now
when
the
event
occurs.
I'll
just
do
some
lightweight
processing
to
send
it
off.
Let
the
other
thread
update
the
data
structure
which
I
don't
need
to
use,
and
that
will
take
some
time
at
the
very
end.
B
A
B
Feels
pretty
good,
nothing
is
six
months
past.
This
has
been
working
in
production.
The
compiler
is
somewhat
faster
than
it
used
to
be,
and
then
she's
doing
something
else
entirely
and,
to
be
honest,
she's
completely
forgotten
that
there
were
threads
in
the
first
place
right
so
she's,
just
working
on
this.
Some
part
of
the
compiler
that
happens
to
be
modifying
that
same
struct.
This
by
the
way
is
rust,
syntax,
but
I
figure.
You
can
probably
figure
it
out.
B
So
this
defines
this
struct
and
this
event
that
happened
to
be
the
thing
that
was
getting
processed
previously,
it
just
had
a
few
integers
in
it,
but
now
she
has
to
add
something
new,
which
is
a
name
which
is
an
intern
string,
and
this
is
where
the
story
gets
a
little
bit
scary.
So
if
you've
done
kind
of
multi-core
programming
or
parallel
programming,
you
know
at
least,
if
you're.
Like
me,
your
heart
starts
to
race
when
you
think
about
all
the
things
that
could
be
happening
now,
because
what
data
doesn't
know
about
that
intern
string.
B
She's
never
actually
had
to
look
at
that
part
of
the
compiler
in
detail
is
that
this
is
how
it's
implemented,
and
this
are
see
of
string.
That's
kind
of
rough
speak
for
a
reference.
Counted
string,
kind
of
like
a
shared
pointer
except
RC,
is
not
atomically
reference
counted.
So
that
means
that
if
two
threads
come
along
and
try
to
modify
the
rest
count
in
parallel,
it
could
be
wrong
right
and
in
particular,
like
I
said,
we
did
just
introduce
this
thread
that
was
going
to
send
these
events
and
send
intern
strings
across
thread.
B
So
there's
a
pretty
good
chance
that
we're
going
to
be
modifying
this
restaurant
in
parallel,
one
of
them
will
probably
get
slightly
off.
This
probably
won't
cause
a
problem
right
away,
especially
because
these
are
intern
strings,
so
there's
always
kind
of
one
big
dictionary
holding
it
at
least
one
rest,
but
sooner
or
later
it's
going
to
cause
a
crash,
or
maybe
just
gibberish
output
or
something
right,
and
it's
going
to
be
a
big
pain
waste
a
lot
of
time
to
debug,
but
actually
none
of
that
happened
because
she
was
using
rust.
B
So
what
actually
happened
was
that
she
got
a
compilation,
error
and
she
said
what
so
the
type
in
turn
string
does
not
implements,
and
that's
kind
of
rust
speak
we'll
get
to
it
more
detail
later.
For
saying
this
is
not
a
thread
fake
type,
and
she
said
why
would
it
have
to
be
thread
say
all
right.
I
have
a
thread
I
forgot
about
that,
and
then
she
went
in
and
changed
it
and
everything
was
fine,
and
this
is
kind
of
the
experience
the
rust
is
aiming
for
it.
B
You
can
do
things
very
easily
to
start
right,
so
you
notice
it
took
her
only
one
day
to
put
those
threads
in.
That's
also
in
well
really
the
stories
about
me
so
I'll
switch
to
the
first
person
now
it
took
me
about
one
day
to
put
those
threads
in
in
the
first
place,
and
that's
only,
but
that's
only
part
of
the
cause
right.
B
The
rest
of
the
cost
comes
later
in
the
maintenance
period
and
we're
Russ
type
system
is
really
great
is
when
it
can
kind
of
deflect
these
things
that
would
have
been
very
painful
and
I
only
take
five
minutes
of
your
day
now
to
fix
it
and
get
the
rest
of
the
system
back
going
right.
So
there
is
kind
of
these
two
parts,
the
productivity
in
the
beginning,
in
the
productivity
in
the
end,
are
the
things
I
want
to
kind
of
drill
into
more
I,
mean
I.
B
B
We
can
call
dot
all
which
invokes
a
closure
on
every
character,
and
this
is
the
closure
syntax
in
rust.
So
we're
saying
for
each
character:
C
is
C
white
space
and
that
compiled
down,
of
course,
the
just
a
little
loop
with
a
pointer
kind
of
bumping
along
this
utf-8
string
right-
and
this
actually
was
a
real-life
example
from
some
people
who
reporting
ruby
code
and
they
had
replaced
like
pages
of
C
code.
B
That
was
doing
the
same
thing
with
this
two
line:
loop
and
it
performed
the
same
and
they
were
very
excited
and
so
the
load
images.
This
is
another
example
doing
parallel
processing
using
in
this
case,
using
a
third-party
library
called
rayon
that
I'll
come
back
to
a
few
times.
It's
something
I
wrote,
but
it's
it's
for
doing,
fork/join
parallelism
and
you
see
that
it
uses
also
iterators
similar
idea,
except
you
just
write
part
it
or,
and
now
you
get
a
parallel
iterator
that
is
executing
in
parallel,
but
it's
also
guaranteeing
data
race
freedom.
B
At
the
same
time,
we'll
see
you
later
and
all
of
these
libraries.
Basically,
rust
is
a
language
geared
around
writing
cool
libraries
that
you
know
lets
you
write,
high-level
things
that
perform
well,
but
the
best
libraries
in
the
world
aren't
that
much
used
if
you
can't
easily
use
them.
So
we
also
have
a
nice
package
manager
which,
which
lets
you
find
the
libraries
and
add
a
few
lines
of
code
and
then
the
compiler
will
download
them
and
build
them
for
you
and
so
forth.
B
So
that's
all
part
of
the
productivity
story,
but
that's
the
first
part.
That's
just
the
writing
code.
To
begin
with,
then
comes
the
safety
and
the
freedom
that
lets.
You
maintain
it
over
time
and
that's
more.
What
I'm
going
to
focus
on
in
this
Mis
talk.
That's
kind
of
the
thing
that
comes
on
top
of
C++
and
I.
Think
if
you
put
these
two
together,
that's
when
you
really
get
to
this
goal
of
productive
systems
programming.
B
The
generic
programming
aspects
a
little
bit
about
parallelism,
don't
worry
about
the
unsafe
thing,
we'll
talk
about
that
and
then
I'll
get
to
some
about
what
feels
like
to
use
rust
kind
of
outside
of
the
technical
parts
like
what
was
it
like
to
get
rust
into
Firefox
and
what
are
some
of
the
community
processes
that
rust
uses
to
grow
and
develop.
So,
let's
start
with
the
memory
safety.
B
So
this
was
our
goal
and
the
interesting
thing
about
these
top
two
bullet
points:
the
zero
cost
abstractions
and
the
memory
safety
and
data
experiment
that
they're
actually
kind
of
in
tension,
there's
a
reason
that
a
lot
of
languages
that
have
safety
don't
also
have
zero
cost
abstraction.
I
know
I'm,
going
to
start
by
looking
at
some
C++
code
to
kind
of
show
you
what
I
mean
so
here.
This
is
a
few
lines
right.
We
already
in
these
few
lines.
We
see
a
few
of
some
of
the
features
that
let
you
build.
B
Zero
cost
abstractions
effectively
like
we
can
make
full
use
of
the
stacks
in
C++.
We
can
put
the
vector
of
strings,
has
the
fields
of
the
vector
or
inline
onto
the
stack,
and
similarly,
the
fields
of
the
string
are
in
lined
into
the
vector.
So
all
in
all,
when
I
want
to
get
to
my
character
data,
it
only
cost
me
two
pointer
dereferences
and
that
matters
a
lot
if
I'm
going
to
put
this
vector
inside
of
a
hashmap
and
put
an
iterator
on
top
of
the
hashmap
and
put
something
else.
B
On
top
of
that,
all
those
layers
start
to
add
up.
If
you
have
to
add
a
pointer
at
each
point,
but
once
you
have
the
idea
of
a
string
being
embedded
in
a
vector
or
what
have
you,
you
also
need
the
Willa
T
to
have
a
reference
right
into
the
middle
of
other
data
structures
might
have
a
reference
that
takes
the
point
of
a
field
or
of
a
particular
array
element.
B
So
this
is
something
of
course,
C++
has,
and
once
you
have
that,
if
you
let
then
layer
on
top
of
it
deterministic
destruction,
meaning
we're
going
to
free
the
memory
of
this
vector
as
soon
as
we
exit
this.
This
function
right.
This
is
where
things
start
to
get
a
little
bit
complicated,
and
so,
if
I
extend
the
example
now
well,
I
will
just
say.
However,
this
makes
things
complicated,
but
it
is
crucial
to
kind
of
maintaining
your
memory
use
over
time
and
keeping
things
from
ballooning
out
of
control.
B
B
Everything
is
consistent,
but
there's
this
dangling
pointer
out
here
this
dangling
reference
of
element,
that's
pointing
now
into
freed
memory,
and
if
I
go
on
and
use
it,
I
can
get
into
trouble
right,
and
even
in
this
simple
example,
we
see
kind
of
the
outline
of
what
happens
if
T
issues
boil
down
to
and
there's
really
two
key
ingredients
that
come
together.
The
first
is,
you
have
to
have
some
sort
of
aliasing,
so
you
have
to
have
more
than
one
path
to
reach
the
same
memory.
B
In
this
case
we
have
the
LM
reference
and
we
have
the
vectors
data
pointer
and
then
you
have
to
have
some
mutation,
because
that's
what
makes
things
get
free?
That's
what
changes
types
like
in
a
union
or
something
this
is
what
kind
of
invalidates
references
and
the
reason
these
two
things
combine
is.
If
you
only
have
one
path
to
a
given
piece
of
memory,
it's
pretty
easy
to
keep
it
up-to-date
when
you
make
a
change
alright.
B
All
the
references
that
are
out
there
in
the
world,
so
what
Russ
tries
to
do
is
to
layer
on
something
we
call
the
ownership
and
borrowing
system,
and
basically
the
key
idea
here
is:
if
aliasing
a
mutation
together
are
the
problem,
then,
let's
just
not
have
them
happen
at
the
same
time,
and
we
do
this
by
having
kind
of
three
main
ways
to
access
data
which
I'm
going
to
go
through
it
one
by
one
right.
So
the
first
one
is
ownership.
B
We
chose
this
word
well,
we
partly
because
it's
in
use,
but
also
I,
think
what
you
have
a
pretty
common-sense
feeling
for
what
it
means
right
so
in
life,
if
I'm,
owning
and
I
have
a
book,
it's
my
book,
it's
on
my
bookshelf
and
I
can
do
a
lot
of
things
to
it.
Right
I
can
write
in
the
margins.
I
can
read
it.
B
One
of
the
things
I
can
do
with
it
also
when
I'm
done
with
it
I
can
give
it
to
somebody
else,
and
now
it's
their
book
and
it's
not
mine
anymore
and
I-
have
nothing
more
to
do
with
it
and
that's
kind
of
how
data
structures
work
in
rust.
So
here's
some
rust
code
and
it
starts
out
by
creating
a
vector
now.
This
is
our
first
glance
at
rust,
syntax,
so
I'm
going
to
just
point
out
a
few
things.
B
The
functions
begin
with
FN
were
from
a
company,
that's
very
familiar
with
JavaScript,
where
the
function
keyword
is
function,
and
it's
very
long.
So
we
tried
to
make
this
one
very
short,
since
you
type
it
a
lot
and
then
inside
of
the
function,
you
can
declare
local
variables
with
let
and
this
vector
all
and
:
new.
That's
invoking,
basically
a
static
method.
Essentially
new
is
not
a
keyword.
It's
just
a
method
that
by
convention,
creates
an
instance
of
the
type
it's
attached
to
and
returns
it
to
you.
B
So
the
representation
at
runtime
will
be
exactly
the
same.
In
C++
we
have
our
fields
on
the
stack
and
I
want
to
highlight
this
mute
keyword
in
rust.
You'll
see
most
things
tend
to
not
be
mutable
unless
you
say
so
in
this
case
we're
declaring
that
we
are
allowed
to
write
to
this
book
and
the
data
that
it
owns
and
that's
kind
of
a
helpful
thing.
B
When
you're
reading
code,
you
can
see
pretty
quickly,
what's
changing,
what's
not
and
so
forth,
I'm
going
to
indicate
that
with
the
little
pencil
there
so
when
I
call
book,
dot,
push
I
get
data
living
in
the
heap,
some
strings
or
what-have-you.
So
far,
it's
pretty
much
the
same
as
what
we
saw
before,
but
where
things
start
to
be
interesting
is
here
when
I
call
publish
you
see
that
it
has
an
argument
which
is
back
of
string.
B
So
if
you
have
a
function
that
takes
a
backup
string
and
rust,
it's
saying
I
need
ownership
of
this
argument.
Give
me
a
vector
all
from
my
very
own
and
on
the
other
side
the
default,
then
is
to
say
well,
I
have
a
vector
you
want
a
vector.
I
will
give
it
to
you
all
right.
It's
not
mine
anymore,
so
a
runtime.
B
What
that
means
is
we
copy
over
the
fields
that
are
on
the
stack
and
the
data
sort
of
transfers
with
that
ownership
transfers
along
and
then
we
kind
of
forget
about
this
field
as
if
we
didn't
have
them
right
so
now
published
can
execute.
It
owns
the
book,
it
has
the
only
access
to
this
book,
it
can
read
it
and
when
it's
done
everything
that
it
owns,
it
can
free
right.
It
runs
the
destructor
and
now,
when
we
come
back,
this
is
where
rust
starts
to
diverge
right.
B
So
we
gave
away
our
book
but
we're
trying
here
to
use
it
again.
So
what
happens?
We
get
a
compilation
error,
because
the
compiler
is
tracking.
What
did
you
own?
What
have
you
given
away
at
each
point
in
the
program
and
it
won't
let
you
use
the
things
you've
given
away
and
we
track
this
on
a
pretty
fine
granularity.
So
you
can
give
away
one
field
of
a
struct,
for
example,
or
for
some
fields,
and
then
we
initialize,
but
usually
it's
just
a
whole
variable
at
a
time.
B
So
this
is
somewhat
different
than
kind
of
copy.
Constructors
right
c++
has
a
very
similar
notion
of
ownership,
but
the
defaults
are
kind
of
switched.
So
if
I
have
that
same
example
what
transliterated
into
C++
it
starts
out
the
same,
we
have
the
memory
layouts
the
same
and
really
when
I
call
publish
in
a
way
the
signature
here
is
the
same.
It's
saying
give
me
a
vector
that
I'm
going
to
own.
However,
what
happens
on
the
other
side
instead
of
giving
them
the
vector
that
we
have?
B
We
would
invoke
the
copy
constructor
and
do
a
kind
of
deep
clone
of
the
data
right
and
now
in
from
publishes
point
of
view.
It's
all
the
same.
They
own
this
book.
You
can
read
it
they'll,
free
it
when
they're
done,
but
when
we
come
back
we're
in
a
very
different
state.
We
haven't
given
away
our
book.
We
still
have
it
and
we
could
call
it
again
and
again
and
again
so
you
can
do
the
same
thing
in
rust.
B
Of
course,
if
you
don't
want
to
give
away
the
thing
you
have,
if
you
want
to
clone
it,
you
can.
You
can
say
that
this
is
rust
code
again
by
calling
clone,
oh
okay,
so
we
kind
of
switch
the
defaults
around
so
essentially
in
rust.
Doing
a
deep
clone
is
explicit.
The
default.
If
you
have
something
that
has
ownership,
it
has
a
lot
of
memory
associated
with
it
is
to
give
on
a
ship
away
which
is
kind
of
a
more
efficient
thing.
So
we
do
have
a
special
case
for
things
like
integers
floating
points.
B
Those
are
what
are
called
copy
types
which
is
kind
of
like
plain
old
data,
and
basically,
as
soon
as
you
touch
them,
they
were
always
cloning
them
implicitly,
because
there's
no
real
memory,
semantics
associated
with
them.
So
ok,
so
there
they're,
not
quite
copy
constructors.
Moves
are
somewhat
similar
to
our
value.
References
at
this
point
we're
getting
past
the
C++
and
learn
in
high
school.
So
if
I
make
a
mistake,
you
know
feel
free
to
correct
me,
but
I
think
I
have
the
basic
gist
right.
B
So
if
we
change
this
program
to
use
standard
move
right,
that's
going
to
create
an
r-value
reference
to
the
book
and
the
net
effect
is
going
to
be
very
similar,
at
least
in
terms
of
runtime,
to
what
happens
in
rust,
right
we're
going
to
copy
over
the
stack
fields,
but
we're
going
to
take
ownership
of
the
memory
and
again
publish
has
its
own
vector,
which
it
can
execute.
However,
again
we're
Ana
slips
turn
it
sorry
the
big
danger
with
animations.
B
However,
we
are
forget
it
we're
in
a
different
state
when
we
get
back
basically
in
the
main
difference
is
that
the
compiler
in
that
variable
book,
it's
still
of
usable
kind
of
variable
lba1
in
that
kind
of
unspecified
state.
At
this
point,
and
in
particular,
its
destructor
will
run
when
we
exit
the
function
and
so
forth.
B
You
can
basically
layer
that
to
build
more
complex
invariants
in
your
age
guys.
So
that's
ownership,
it's
fairly
straightforward.
It
is
the
most
common
thing,
but
actually
in
real
life,
or
at
least
it's
a
very
common
thing,
but
in
real
life
you
know.
Usually,
if
I
give
my
book
to
someone
I'm
not
saying
take
it
forever,
I'm
saying
here
once
you
read
it
and
give
it
back
to
me
when
you're
done
right
and
that's
usually
what
we
want
to
do
with
data
structures
too.
B
So
that's
where
borrowing
comes
in
and
there's
two
kinds
of
borrows
in
rusts,
the
first
one,
the
most
common
one
is
what
we
call
a
shared
reference.
It's
written,
ampersand,
T
and,
like
the
name
suggests,
it
allows
sharing,
but
we'll
see
that
it
does
not
allow
mutation,
because
we
said
we
want
to
keep
those
two
things
separate.
B
This
is
just
going
to
be
a
pointer,
that's
what
an
ampersand
on
back
of
string
is
represented
as
and
we
saw
that
it's
going
to
disallow
mutation,
so
I'm
going
to
go
into
more
detail
net
after
this
slide.
But
for
now,
I'll
put
the
little
slash
to
show
what
I
mean
so
now
published
can
execute
and
it
has
a
borrowed
copy
of
the
book
as
a
pointer
to
the
book.
B
So,
let's
see
now
this
mutation
thing
I
have
this
theory
that
you
can
kind
of
everything
you
need
to
know
about
rescue
learned
in
kindergarten
which
is
kind
of
what
I
say.
We
don't
break
your
friends
toys
just
kind
of
when
you're
sharing
something
if
you're
borrowing
someone
else's
saying.
At
least
you
really
shouldn't
be
breaking
your
writing
into
it
and
so
forth.
You
should
be
nice
to
it
and
that's
kind
of
what
happens
with
shared
references
right.
So
when
we
first
create
the
book
here.
This
is
a
combined
snippet
in
one
function.
B
When
we
first
create
the
book
it's
in
a
mutable
state
and
we
own
it.
So
we
can
do
things
like
call
book
push
and
that's
fine,
but
when
we
enter
into
this
block-
and
here
I'm
just
using
the
block
to
scope,
the
variable
R
doesn't
have
anything
else
any
other
purpose,
and
we
make
this
reference
we're
putting
the
book
into
a
borrowed
state
the
compilers
mind
right,
and
that
means
that
during
this
period
where
the
reference
is
in
use,
we
can't
do
mutations
on
books.
B
So
we
couldn't
call
book
dot,
push
that
wouldn't
be
allowed
and
we
similarly
can't
call
through
the
reference
to
the
book.
We
can't
call
r
dot
push
both
of
those
would
do
the
same
thing
effectively
if
we
allowed
it.
So
you
see
here
that
we
have
two
paths
to
the
same
book.
You
can
go
through
the
original
variable
book
where
you
can
go
through
R
and
you
could
also
copy
R
and
make
many
references,
and
none
of
them
allow
mutation
to
also
see
that
mutation
and
rust
is
not
a
binary
thing.
B
It's
not
like
this
is
immutable
forever
or
mutable
forever.
It's
really
about.
In
this
period
it's
mutable,
or
in
this
period
it's
not-
and
that's
particularly
here,
because
when
we
exit
this
scope,
the
variable
R
is
going
out
of
scope
now
the
Baro
ends,
and
that
means
that
we
can
again
call
book
dot.
Push
that's
perfectly
legal
at
this
point
since
there's
no
references
to
it.
B
So
I
should
add
one
caveat,
I've
been
saying
immutable
and
mutable
this
whole
time,
and
that's
actually
a
little
stricter.
There
are
ways
to
mutate.
Shared,
alias
memory,
but
you
have
to
go
through.
Special
IP
is
essentially
have
to
use
unsafe
code,
which
I'll
talk
about
later,
so
an
example
where
you
would
want
to
do
that
might
be
a
mutex.
That's
protecting
some
data.
B
If
you
couldn't
share
it,
you
would
just
have
the
mutex
in
one
thread:
that's
not
that's
kind
of
pointless,
so
you
would
want
to
be
able
to
share
it
amongst
many
threads
and
then
have
them
each
acquire
the
lock
to
gain
access.
That's
an
example
of
a
kind
of
special
API
that
enables
mutation
what
the
default
is.
If
it's
shared,
you
can't
mutate
it.
B
Okay,
so
that's
a
shared
reference
and
the
other
kind
of
reference
is
a
mutable
reference
and,
as
you
might
expect,
if
you've
been
following
this
table,
a
mutable
reference
allows
mutation
but
doesn't
allow
for
sharing
right.
Let
me
show
you
what
I
mean
so
here's
my
code
example
I
have
a
mutable
reference
to
a
vector
here.
It
looks
a
lot
like
the
shared
reference,
but
it
has
a
mute
keyword
in
it,
so
signaling
we're
going
to
do
mutation
now
and
on
the
other
side.
B
Instead
of
writing
embassy
and
book
are
writing
ampersand,
mute
book
so
again,
if
you're
reading,
through
you
sort
of
see
where
the
mutations
are
happening
at
runtime.
This
is
exactly
the
same
as
a
shared
reference.
It's
just
a
pointer,
but
in
the
compilers
mind
it
has
a
different
significance.
Instead
of
making
that
that
pencil
go
to
an
immutable
state,
it
goes
to
a
kind
of
locked
state
where
we're
not
going
to
allow
access
to
the
original
variable
at
all.
B
So
now
we
can
run
our
function,
it
can
make
changes
through
this
reference
and
they
will
affect
the
original
variable.
So
we
pushed
on
to
the
book
and
we
could
call
it
again.
We
haven't
given
ownership
away
and
all
these
things
can
happen
while
we
remain
the
owners
right.
So
how
does
it
look?
What
does
it
mean
to
block
out
all
access?
B
Well,
this
is
a
the
same
kind
of
format
here
and
we
can
walk
through
and
we
see
that
initially
the
book
is
mutable
just
like
before,
but
when
we
make
a
mutable
reference
here,
we're
borrowing
it
mutable.
Now
it's
a
little
bit
different
before
you
couldn't
do
any
mutations,
but
either
using
either
path.
You
could
do
reads
now.
If
we
try
to
use
the
original
path,
the
book
even
just
to
read
it
just
to
get
it
length,
we
get
an
error,
but
if
we
try
to
use
the
reference,
we
can
do
anything
we
want.
B
B
Actually,
we
found
that
this
scale
better
in
various
ways,
but
one
of
the
reasons
that
it's
very
easy
to
see
is
that
when,
when
the
rep,
the
mutable
reference
has
soul
complete
access,
it
means
you
can
do
a
lot
of
things
like,
for
example,
you
could
send
it
to
another
thread.
You
can
be
sure
that
the
original
thread
no
one's
reading
from
it
from
the
current
thread
right
I'm,
not
reading
through
it
through
a
book.
Well,
another
thread
writes
to
it
from
R
that
would
induce
the
data
race
and
we'll
see
that
later
on.
B
B
If
we
were
going
to
write
it
explicitly,
I
might
look
like
that,
where
we
would
say:
ampersand
tick,
L
string,
so
this
tick
L
the
tick
represents
lifetime,
and
that
means
that
a
lifetime
was
named
L,
that's
the
lifetime
of
this
reference,
and
it
refers
to
this
span
of
code.
So
we're
saying
this
is
how
long
the
reference
is
valid
for
how
long
it
can
be
used.
The
compiler
won't
allow
you
to
have
the
reference
outside
of
that
lifetime.
B
So
you
don't
have
to
worry
about
this
within
functions.
It's
all
implicit
and
in
fact
we
don't
even
have
a
syntax
for
naming
it
within
a
function,
although
I'd
like
to
add
one
but
across
functions,
is
very
useful.
So
this
is
a
function
that
returns
a
reference
to
the
zeroth
element
of
the
vector
that
you
give
it
right,
and
you
see
these
e
annotations
here.
What
these
are
basically
saying
is
they're
they're
telling
the
caller
who
doesn't
know
what
the
functions
body
is.
What
this
reference
is
that
it's
being
returned?
Where
does
it
come
from?
B
In
this
case,
we
have
elision
rules
that
let
you
allied
those
things
but
in
sometimes,
if
you
have
many
references,
can
be
important
to
clarify
where
the
value
is
coming
from
and
where
it's
not,
and
then
that
allows
us
to
kind
of
track.
These
borrows
across
functions
right.
So
if
we
have
this
function
first-
and
we
have
an
example
here-
I'm
borrowing
book,
but
all
I'm
doing
with
the
book
you
see
instead
of
before
I,
was
directly
assigning
it
to
a
variable.
So
the
compiler
could
easily
see
what
was
happening
here.
B
I'm
passing
it
to
a
function
which
is
returning
to
us
something
right
and
the
compiler
can
use
these
annotations
basically
or
you
to
track.
What's
happening
and
say:
ok,
this
reference,
some
sub
part
of
this
reference
is
going
to
be
stored
into
R
and
R
is
used
in
this
block,
so
I
can
figure
out
that
book
is
basically
borrowed
until
that
reference
are
goes
out
of
scope,
and
that
means
in
particular
we're
not
going
to
allow
you
to
say
modify
book
here.
B
Even
though
there's
no
direct
reference
to
book
anymore,
I've
got
passed
away
all
right,
so
that's
kind
of
the
heart
of
rust,
essentially
when
I
just
covered
the
ownership
and
borrowing
system,
or
at
least
one
of
the
the
key
pipes
of
rust.
But
the
other
key
part
is
our
approach
to
generic
programming.
I
think
this
is
another
place
where
we
took
a
lot
from
C++
and
we've
tried
to
add
on
to
it.
B
Some
other
influences
in
particular,
some
of
them
from
Haskell,
so
I
called
this
section
traits
traits
are
very
like
the
cornerstone
basically
of
generic
programming
in
rust
and
I.
Think
you
can.
There
are
some
one
analogous
to
a
concept
I'm
sure
the
details
are
very
different.
Unfortunately,
this
is
like
clipping
some
parts
of
the
display,
but
what
that
should
say
is
trait
clone,
and
it's
so
we've
actually
seen
this
already
earlier.
I
said:
if
you
want
to
clone
a
book,
you
could
call
book
clone
what
that
was
actually
invoking
was
a
generic
method
called
clone.
B
That's
defined
in
this.
This
trait,
and
so
a
trade
is
sort
of
like
an
interface
that
you
implement
for
a
given
type
and
they
can
have
associated
types.
They
can
have
different
kinds
of
members.
The
most
common
one
is
a
function,
so
here
I'm
saying
clone
is
an
interface
with
one
method
and
the
signature
of
this
method.
So
you
see
these
different
references
to
self.
The
first
part,
the
ampersand
self,
with
the
lowercase,
that's
declaring
the
receiver
so
see
the
the
this
keyword
is
kind
of
implicit
in
C++.
B
B
We
do
the
type
checking
once
on
this
generic
specification,
not
on
each
individual
instantiation
and
that's
where
these
requirements
come
in.
So
this
imple
is
saying:
is
here's
how
you
clone
a
vector
for
any
type
T,
provided
that
T
itself
is
cloneable
right
and
that's
because
when
you
clone
a
vector,
you
also
clone
all
of
its
contents.
So
they
have
to
be
cloneable
in
the
actual
implementation.
B
We
can
create
a
new
vector
here.
Ty
was
something
like.
We
just
saw
only
I'm,
calling
it
V
and
then
we
iterate
over
it
I
don't
have
time
to
go
into
exactly
how
this
works,
but
basically
LM
here
is
going
to
be
we're
going
to
create
an
iterator
and
LM
is
going
to
be
a
reference
to
each
element
in
the
vector
in
turn.
B
Right,
so
ampersand
T
will
be
its
type
and
on
each
of
those
references,
I
can
call
the
clone
method
and
then
I
get
back
a
value
of
type
T
that
I
can
push
into
the
vector
and
when
I'm
done,
I
return
the
completed
vector.
So
this
is
a
very
simple
way
to
clone
a
vector
so
most
of
the
time
when
you're
doing
generic
programming
you're
first
of
all,
using
traits
and
you're
using
methods,
but
we
also
have
some
traits
that
don't
have
any
members
at
all
right
there.
B
We
call
them
marker
tricks
and
these
basically
express
properties
of
the
type
they
don't
have
operations
themselves,
that
they
will
enable
other
things.
Some
of
these
are
built
into
the
language.
Some
are
not
so
here's
two
examples,
both
of
which
have
come
up
briefly
in
this
sock,
so
the
send
one,
the
first
one-
that's
not
really
built
into
the
language,
but
that
defines
types.
There
are
thread-safe
and
types
that
are
not,
and
so
you
know
anything
that
kind
of
owns
its.
B
Its
data
will
be
considered,
sent
it
will
have
implementation
percent
and
it's
using
some
various
language
features
so
that
it's
basically
automatic
we
detect.
We
have
a
conservative
approximation
for
things.
There
are
threads
days
and
we
automatically
have
such
a
trade
beacon
has
to
type
be
considered,
thread
takes
so
like
strings
integers
and
so
on.
B
Similarly,
our
C
string
would
be
ruled
out
by
this
conservative
check,
but
archive
string
is
not
automatically
considered
thread
safe,
but
it
uses
unsafe
code
which
look
into
later
to
kind
of
ops
back
in
and
say,
I
know
this
looks
dangerous,
I'm,
manipulating
this
shared
state,
but
I'm
doing
it
in
a
thread
safe
way.
So
trust
me
on
that,
and
then
we
saw
copy
I
mentioned
that
for
integers
and
things
there's
no
ownership
tracking
copy
is
a
marker.
B
Trait
that
says,
any
type
that
implements
copy
can
be
mem
copied
from
place
to
place
and
so
for
floating
points,
integers
and
so
on.
That
works.
This
one
is
completely
built
into
the
language,
because
it's
so
core
to
the
type
checking
things
that
have
destructors
like
strings
and
RC
strings,
and
also
things
that
might
have
destructors
in
the
future
like
types
that
you
define
are
not
automatically
copy,
you
have
to
kind
of
opt
in
to
say,
you're
allowed
to
treat
this
as
copy.
C
B
No,
so
the
question
was:
are
c-string
does
not
support
sin,
so
what
would
happen
if
I
tried
to
add
it
myself
all
right?
Basically,
and
the
answer
is
you
can't
do
that
because
there
are
rules
called
coherence,
rules
which
basically
define
who
is
allowed
to
implement,
which
traits
for
whom?
And
so,
if
you
define
a
type,
you
are
the
only
one
that
is
allowed
to
implement
traits
that
you
can,
that
you
can
see
source
peak.
So
sin
is
in
the
standard
library
if
you're,
typed
and
and
also
string
is
in
the
standard
library.
B
So
only
the
standard
library
can
implement,
send
or
not
implement
it
for
string,
let's
say
and
RC.
But
if
you
define
your
own
type,
then
yes,
you
could
choose
whether
to
implement,
send
or
not
for
that
type.
Similarly,
if
you
define
your
own
trait,
you
could
implement
it
for
a
string,
but
you
have
to
have
define
one
of
the
two
that
way
we
prevent
there
from
being
conflicting
implementations
for
a
given
type.
B
B
The
question
is,
if
there's
two
libraries,
one
of
which
defines
the
trait
and
one
defines
the
type
they
have
to
know
about
each
other
to
a
certain
extent
right,
and
the
answer
is
yeah
at
the
moment
they
do.
We
have
different
features
for
that
in
the
package
management
system,
so
you
can
kind
of
have
optional
dependencies.
One
of
them
have
an
optional
dependency
on
the
other,
so
that
people
can
say
hey
I
want
to.
If
you
happen
to
be
using
both
of
these,
then
please
do
provide
this
info,
but
it's
an
interesting
challenge.
B
B
B
A
B
Actually,
one
part
of
the
solution
we've
been
thinking
about
is
just
to
make
that
easier
to
do
so,
since
it's
often
good
enough.
Ok,
so
I
want
to
talk
a
little
bit
about
parallelism
and
I'm,
going
to
lean
here
just
a
little
bit
on
the
last
two
sections
right
on
ownership
and
borrowing
and
on
generic
programming,
and
the
reason
for
that
is
that
rust
actually
has
taken
a
big
turn
in
its
development.
When
it
comes
to
parallelism,
we
always
wanted
to
have
a
language
that
was
at
strong
support
for
parallelism.
B
We
can
actually
move
all
of
this
into
libraries
and
they
can
leverage
these
two
systems
to
to
avoid
databases
and
give
all
the
same
guarantees
that
we
thought
that
the
language
had
to
provide.
So,
in
fact,
rust,
the
language
knows
basically
nothing
well,
let's
just
say
very
little
about
threads.
It
has
a
few
intrinsics
for
doing
atomic,
add
and
stuff
like
that,
but
other
than
that,
it
basically
doesn't
really
know
much
about
threads
and
that
all
comes
in
at
the
library
level.
B
So
it
turns
out
ownership
and
borrowing
are
they
were
we
developed
them
for
sequential
programming,
but
they're,
really
a
good
tool
for
avoiding
databases,
and
if
you
look
at
the
definition
of
what
a
data
race
is,
it
kind
of
makes
sense
right.
So
a
data
race
is
this
very
common
era
where
basically,
two
threads
share
access
to
one
piece
of
memory.
At
least
one
of
them
is
writing
to
it.
Maybe
both
and
they're
not
coordinating
with
one
another
right
they're,
not
using
any
kind
of
ordering
to
do
that.
B
So
this
is
basically
the
first
half
of
this
talk
right.
It's
all
about.
Can
we
avoid
sharing
in
mutation?
So,
if
we're
avoiding
sharing
your
mutation
by
default,
we
kind
of
don't
have
data
races
at
all,
and
the
only
problems
that
you
have
to
be
careful
about
is
when
you
introduce,
sharing
mutation
back,
like
I
said,
maybe
with
a
mutex
or
something
and
that's
when
your
API
has
to
make
sure
that
ordering
is
enforced.
B
So
here's
a
cool
example:
it's
not
cut
off
too
badly.
It's
a
parallel
quicksort
and
it's
using
rayon,
which
is
this
library.
I,
was
talking
about
earlier
for
doing,
fork/join
parallelism.
It
uses
the
few
rough
features
we
haven't
seen
it.
So
let
me
walk
you
through
it.
First
off
the
the
input
to
this
is
a
mutable
reference
to
a
slice
of
integers
and
the
slice
is
kind
of
like
an
array.
It
has.
B
You
know
a
number
of
I
32
s,
those
are
32-bit
integers
sequentially
in
memory,
and
it
comes
with
a
length
also,
so
we
can
do
bounds,
checking
and
we're
going
to
do
the
usual
quicksort
thing.
So
we're
going
to
pick
if
it's
only
one,
it's
sorted
already.
Otherwise
we
pick
a
random
element
and
we
partition
to
the
to
the
left
and
right
so
that
we
sort
kind
of
partially
the
elements.
Then
we're
going
to
call
this
split
up
mute.
That's
a
library
method
that
takes
in
a
slice
and
a
midpoint.
B
So
it
gives
you
back
to
the
kind
of
two
views
onto
the
same
memory
which
are
split
at
that
midpoint
and
so
less
and
greater
are
now
referring
to
kind
of
the
left
and
right
halves
of
this
input.
And
it
might
seem
like
we're
violating
the
the
prime
directive
here
by
having
aliasing.
Since
now,
we
have
kind
of
a
path
through
vector
and
a
path
through,
less
and
greater,
which
can
reach
the
same
elements.
B
But
that
doesn't
happen
because
of
the
features
I
was
talking
about
earlier
kind
of
low,
but
basically,
where
the
function
declares
when
it
returns
its
references.
We
know
where
they
came
from,
and
so
we
know
that
less
and
greater
were
derived
from
Veck,
because
they're
all
annotated
with
the
same
lifetime
today,
and
so
we
can
figure
out
that.
Therefore,
while
the
less
and
greater
are
in
use,
the
vector
is
considered
borrowed
right.
So
when
you
call
split
at
mood,
you're
effectively
trading
in
I
had
a
reference
to
the
whole
array.
B
Okay,
so
the
question
was:
do
I
also
specify
that
the
ranges
don't
overlap?
That's
a
good
question
and
I
will
get
into
it
a
little
bit
and
then
a
little
bit
next
slide,
but
in
this
case
they
can't
overlap
sort
of
by
definition,
because
we
gave
one
midpoint
and
we
said
zero
to
mid
and
mid
over
and
those
do
not
overlap
right.
We
didn't
give
two
independent
ranges,
but
yes,
we
might
have
a
bug
in
our
implementation.
That's
right
so
well,
like
I,
said,
that's
coming
up
actually,
if
it's
perfect
lead-in
to
a
later
slide.
B
So
so,
okay,
let's
assume
for
now
that
split
up
Mew,
is
correctly
implemented,
and
we
have
two
disjoint
views
onto
the
original
array.
Then
we
can
call
this
method.
Ray
on
join,
so
join
is
a
method
to
find
sort
of
function.
I
guess
defined
in
the
Ray
on
crate,
which
is
the
library
and
what
it
does
is
it
takes
two
closures
as
argument.
B
All
it
knows
is
that
whenever
you
have
two
closures
that
exist
at
the
same
time,
they
can't
both
have
access
to
the
same
mutable
state,
because
that
would
violate
our
prime
directive
right.
Our
prime
rules,
so
basically
here
the
compiler
will
already
check
that
the
set
of
variables
at
least
mutable
variables
or
yeah
the
set
of
variables
that
each
closure
mutates.
Let's
put
it,
that
way,
is
disjoint.
So
here
we
have
less
than
one
and
greater
than
the
other.
B
If
I
made
a
mistake
like
say,
I
used
less
in
both
or
Veck
in
one
the
compiler
would
flag
it
as
an
error
right
and
all
that
happens.
Kind
of
by
the
base
system
and
rayon
doesn't
have
to
specify
anything
about
that,
and
that
sounds
like
the
unusual
bug,
but
actually
I've
made
that
mistake
several
times.
I
have
an
I
copy
and
paste
code.
Yep.
B
Okay,
so
the
question
was
the
closures:
are
they
implicitly
borrowing
by
mutable
reference?
That's
a
good
question!
Sorry,
yes,
effectively!
What
we
do
is
we
analyze
the
closure
body
and
for
each
variable
we
figure
out
essentially
a
mode,
so
it
can
be
by
value
or
by
shared
reference
or
by
mutable
reference
and
that's
based
on
how
you
use
it.
B
B
B
Okay,
so
the
question
is:
does
the
inference
take
into
account
what
I
will
do
with
the
closure?
The
answer
is
yes,
it
does
sort
of
so
the
they're,
the
closures
themselves,
they're
callable,
right
and
there's
a
trait
for
being
callable,
and
so
the
way
it
closed
a
bit
the
base.
The
model
closure
is
very
similar
to
the
C++
model.
B
Essentially,
they're,
like
a
independent
anonymous
structure,
has
their
various
things
that
they
touch
as
its
members
and
they
may
implement
one
or
more
of
these
various
callable
traits,
and
there
are
three
of
them
one
for
let's
see
one
for
my
ownership,
one
for
shared
reference
and
one
for
mutable
reference,
and
so
when
you
would
declare
your
function.
You're,
basically
saying
like
when
I
declare
join
I'm,
saying
I
need
two
closures
and
I
have
two
special
ease
trade
based
on
how
I'm
going
to
use
it.
B
So
in
this
case,
I
would
take
the
ownership
version,
because
I'm
going
to
take
these
closures
and
send
them
to
different
threads,
so
kind
of
they're
only
going
to
get
executed
once
and
so.
There's
a
there's
like
a
two,
the
two
parts,
the
the
one
who
gets
the
closure,
basically
declares
the
conditions
under
which
they
will
call
it.
B
B
Yes,
so
that's
the
reason
that
it's
called
split
add
mute
is
that
you're
declaring
that
you're
taking
you're
getting
back
to
mutable
references
there's
also
a
split
at
that.
Doesn't
have
that
characteristic,
and
so
the
thing
I
want
to
emphasize
I
kind
of
brought
it
up
earlier,
but
the
whole
reason
that
this
works
at
all
the
reason
we
can
send
mutable
references
to
other
threads
without
kind
of
just
because
they're
part
of
the
closure
is
because
of
these
rules.
That
say
when
you
have
a
mutable
reference,
there
is
no
aliasing
right.
B
B
Do
we
have
a
plan?
Do
we
plan
on
specifying
the
type
of
the
capture
so
I
did
I
think
the
answer
is
I
left
out
one
thing:
actually
there
is
a
single
flag
you
can
use,
you
can
write
in
front
of
the
closure
move
and
then
the
closure-
and
in
that
case
you
are
declaring
that
you
take
ownership
of
everything
that
you
touch
and
you
do
that
specifically
when
the
closure
is
going
to
be
returned
out
of
the
function
or
in
some
way
escape
the
current
stack
frame.
B
No,
we
don't
do
it
implicitly
because
it
actually
affects
the
semantics
in
some
cases
like.
If
you
have
a
single
variable
and
you
increment
it
are
you
incrementing
the
one
on
the
stack
or
your
own
copy,
which,
which
one
are
you
changing,
so
move
kind
of
declares?
Do
you
want
your
own
copy
of
the
variables
or
do
you
want
to
use
the
copy
from
the
stack
and
I
think
using
it's
useless,
I
should
just
say
using
move.
B
B
Oh,
it
also
builds
on
traits
I
got
distracted
by
all
the
questions,
but
I
should
say
that
the
one
thing
rayon
join
does
say
it
says:
I
take
two
closures:
it
doesn't
tell
the
compiler
they're
running
in
parallel,
but
it
does
require
that
everything
they
touch
is
send
about
right
and
we
talked
about
send
earlier
because
it's
going
to
send
them
to
other
threads,
so
you
better
not
be
using
an
RC
or
something
that's
not
thread
safe
in
there,
so
it
leans
on
borrowing
in
traits.
We
also
have
other
things
right.
B
We
have
like
message
passing
this
is
built
into
the
standard
library.
You
can
sort
of
imagine
that
message
passing
is
just
ownership
transfer.
If
I
have
some
data
I
want
another
thread
to
have
it
I
just
give
ownership
of
it
and
it's
good.
The
only
requirement
is
the
data
is
sent.
That
was
the
thing
that
ADA
ran
into
in
the
very
beginning
right
and
we
support
laughing.
B
So
if
you
have
we
dreadlocks
and
normal
mutexes,
if
you
have
two
threads,
if
the
baby
is
set
up
so
that,
basically,
if
there's
some
data
is
protected
by
a
lock,
the
lock
owns
that
data
and
hence,
if
you
want
to
get
access,
you
have
to
go
through
the
locks,
meaning
you
have
to
acquire
the
lock.
So
you
can't
forget
to
acquire
the
lock
and
so
forth.
Then
we've
doing
actively
now
I
would
say
a
lot
of
work
on
lock,
free
data
structures
and
future
style
programming
for
asynchronous
I/o
and
so
on.
B
It
has
this
relatively
simple
patterns
of
ownership,
shared
reference
and
meetable
reference,
which
is
enough
most
of
the
time
but
doesn't
cover
everything
you
want
to
do
when
it's
already
seen
some
exceptions
to
that,
like
RC
and
so
on,
and
for
those
things
the
way
we
do
it
is
we
have
the
ability
to
opt
out
and
go
into
a
superset
of
rust.
We
call
unsafe
rust
and
basically
you
write
a
write,
a
block
of
code
using
unsafe,
and
then
you
can
kind
of
break
the
rules.
B
You
can
have
essentially
C
pointers
that
point
anywhere
it
can
be
shared,
they
can
be
mutable,
however,
you
choose,
and
on
the
other
side
the
idea
basically,
is
not
that
you'll
just
take
these
unsafe
blocks
and
kind
of
sprinkle
them
anywhere
in
your
code
that
you
happen
to
be
getting
a
type
error,
I
mean
you
can
do
that.
Some
people
do
that,
but
that
wouldn't
be
the
best
practice.
B
Instead,
the
idea
is
that
you're
supposed
to
build
an
abstraction
around
it
that
is
safe,
right
and
so
split
up
mute
is
an
example
of
such
an
abstraction
and
there
is
some
responsibility
there.
So
the
question
earlier
was
like:
how
do
we
know
that
they're
disjoint,
the
compiler,
doesn't
know
it
trusts
us
that
they're
destroying
and
we
could
design
the
API
in
such
a
way
that
we
have
a
bug
and
we
accidentally
give
off
overlapping
ranges
in
this
case,
like
the
logic
is
fairly
straightforward,
we're
pretty
confident
that
they're?
B
Not
so
you
know
it
can
be
subtle
sometimes,
but
we
know
that
we're
not
going
to
be
able
to
kind
of
prove
everything
that
humans
can
do
right.
So
that's
not
a
goal
of
ours.
It's
just
to
get
the
most
of
your
code
should
not
be
using
unsafe
and
the
nice
part
about
this
is
when
you
have
a
problem.
If
you
have
a
crash,
you
have
a
pretty
good
idea
where
to
go
looking
right,
those
unsafe
blocks
and
those
unsafe
abstractions.
Maybe
you
made
a
mistake
in
one
of
those.
B
So
I
was
trying
to
get
some
good
statistics
to
give
an
idea
of
how
often
unsafe
I
know
you
can't
read
that.
Don't
worry
how
often
unsafe
code
comes
up.
I
was
working
with.
Diane
house
fell
to
the
someone
who
works
on
servo,
which
I
haven't
talked
about
yet,
but
servo
is
a
project
I'll
talk
about
in
a
bit
and
she
has
a
tool
for
measuring
how
much
unsafe
code
there
is
relative
to
other
code
turns
out.
This
is
actually
kind
of
a
hard
thing
to
measure,
but
we
did
our
best
within
the
russ
compiler.
B
For
example,
we
came
up
with
this
number,
so
the
russ
compiler
is
350
thousand
lines
of
code
more
or
less.
It's
actually
excluding
some
kind
of
some
part
of
it,
but
and
approximately
4%
of
that
is
around
in
the
routine-
is
unsafe,
meaning
they're,
unsafe
blocks
kind
of
in
its
vicinity,
and
a
lot
of
that
is
basically
because
we
call
LLVM.
So
if
you
think
about
it,
calling
into
c
code
is
kind
of
inherently
unsafe
right.
You
can
do
whatever
it
wants.
So
there's
not
much.
We
can
do
about
that.
B
So
bindings
tend
to
be
a
really
heavy
source
where
you
bind
to
C
in
C++,
libraries
tend
to
be
a
really
heavy
source
of
unsafe
code,
but
that
gives
you
a
feeling,
I
mean
I,
would
say
my
daily
usage,
essentially
I,
never
well.
Okay,
I
very
rarely
write
on
safe
code
unless
I'm
working
on
rayon,
which
is
that
library
for
multi
fur
for
work-stealing,
which
yes,
the
core
of
it,
is
written
in
unsafe.
But
even
there
we've
actually
factored
the
library
into
two
parts.
B
So
there's
a
core
abstraction
which
you
don't
change
very
often
that
does
the
work
stealing
and
then
all
the
like,
parallel
iterator
API
is
and
all
that
stuff
those
are
all
safe
or
just
layered,
on
top,
which
is
really
cool,
because
when
we
get
pull,
requests
from
people
who
are
most
of
them
are
targeting
that
stuff.
We
don't
have
to
review
those
ads
closely
right.
A
few
basic
tests
is
enough.
B
So
we've
we've
recently
shipped
rust
in
Firefox,
as
I
said,
it
was
not
a
kind
of
completely
no-brainer
decision
for
one
thing:
Firefox
is
a
very
big
C++
code
base
and
we
are
not
going
to
rewrite
the
whole
thing
at
once
right,
so
what
we
tried
to
do
actually
before
I
go
into
this.
What
we
tried
to
do
in
parallel
with
developing
rust
is
we
were
working
on
a
project
called
servo
I
mean
servo
is
a
essentially
a
reimagining
of
if
you
did
rewrite
everything
from
scratch.
B
If
you
said
okay,
instead
of
taking
gecko,
which
was
built
in
the
90s
for
unicore
processors
without
GPUs-
and
we
wanted
to
say
how
would
we
render
our
webpage
now
with
today's
computers?
What
would
it
look
like?
That
was
a
big
task
and
we
had
a
lot
of
early
success
and
I'll
talk
about
later,
but
kind
of
all
of
that
informs
the
advanced
features
that
we
might
want
to
bring
into
Firefox
eventually.
B
But
when
it
came
time
to
really
put
rust
in,
we
went
looking
for
something
smaller,
something
that
could
be
basically
the
smallest
amount
of
rust
code
that
we
could
actually
put
in,
so
that
we
would
then
have
to
do
all
the
other
work,
which
is
to
make
files
which
is
testing
that
we
support
all
the
different
platforms.
For
example,
rust
did
not
support
win
XP
at
that
time,
and
all
these
different
things,
they're
Firefox
targets,
and
so
the
choice,
the
first
one
turned
out
to
be
an
mp4
D
mixer.
B
So
this
takes
in
an
mp4
video
parses,
the
header
splits
it
out
into
audio
and
video,
and
this
code
was
written
already
in
C++.
It's
actually
a
kind
of
simple
operation,
but
it's
a
common
source
of
security
vulnerabilities.
This
sort
of
thing
right,
because
it's
all
these
indexing-
and
there
are
these-
mean
people
who
will
like
write,
mp4
files
that
are
specifically
looking
at
your
code
and
the
bugs
in
it
trying
to
take
over
your
machine
and
so
rusting
like
that's
a
pretty
good
choice
for
that.
B
Actually,
when
this
shift,
so
this
is
now
shipping
should
say,
I
think
it
shipped
in
well
I
guess
here
on
the
slide,
you
probably
can't
see
it,
but
it
says
2016
March.
Since
then.
What
you're
looking
at
here
this
big
blue
circle
is,
is
the
telemetry
of
Firefox,
so
for
users
who
opted
in
some
percentage
of
them,
we
send
data
back
on
kind
of
different
measurements
and
and
and
one
of
the
measurements
is.
B
We
ran
this
rust
code
in
parallel
with
the
C++
code,
so
we
didn't
trust
it
fully
yet,
and
we
checked
if
they
do
exactly
the
same
thing,
and
this
was
how
many
times
was
that
successful.
So
that's
one
hundred
percent,
so
that
was
pretty
cool,
and
so
this
is
run
now
about
1.2
billion
times
out
in
the
world,
and
so
this
was
kind
of
our
first,
our
first
foray.
B
We
have
a
couple
other
similar
things
like
this
planned
I,
don't
know
if
they'll
make
it
or
not
so
one
example
is
the
URL
carcere
another
thing
which
actually
back
when
I
was
working
at
that
company
DataPower
I
remember.
That
was
the.
If
you
were
mad
at
someone,
you
were
like
all
right:
it's
your
job
to
work
on
the
URL
parser
now
because
it
seems
so
simple,
but
it's
really
hard.
Surprisingly,
especially
when
you
get
data,
URLs
and
all
of
those
stuff
and
another
place
where
people
can
craft
and
try
to
attack
your
machine.
B
So
these
these
kind
of
targeted
areas
are
good
places
to
introduce
rust
in
a
sort
of
narrow
way,
all
right
and
I
should.
One
of
the
things
I
wanted
to
mention
here
is
that
Russ
does
make
this
pretty
easy
right.
So
we
support
the
C
ABI
natively
and
our
structure
layout
can
be
made
completely
compatible
with
C
C
structures.
So
you
can
very
easily
call
it
into
rust,
from
C
and
into
C
from
rust,
and
vice
versa.
Back
and
forth.
B
C++
is
a
little
bit
trickier
because
it
has
such
a
rich
set
of
features
right
and
we
don't
support
all
them
we're
working
on
tools.
There
are
the
people
who
did
this
work
of
or
who
have
also
done
a
lot
of
work
as
we'll
get
to
in
a
second
integrating
with
the
C++
code
and
Firefox
and
they've
had
to
support
you
know
templates
in
the
classes
and
the
different
data
layouts
and
so
on.
So
we
have
some
tools
for
doing
that,
but
it's
still
a
work
in
progress
so
right.
B
So
what
are
the
next
steps
beyond
mp4
headers
and
URL
parsers?
So
I
mentioned
this,
this
servo
project,
which
was
kind
of
looking
at?
How
could
we
do
that?
How
could
we
do
that?
The
rendering
engine
differently-
and
there
were
two
main
things
that
are
now
coming
from
that
project
into
Firefox
itself?
One
of
them
is
something
called
stylo,
and
this
is
kind
of
an
interesting
story.
So
stylo
does
CSS
selection,
which
I
don't
know
how
much
you
know
about
CSS,
but
basically
there's
an
HTML
Dom.
B
It's
like
a
big
tree
and
you
walk
down
and
based
on
some
predicates,
you
assign
different
styles
and
so
on,
and
it's
kind
of
an
embarrassingly
parallel
problem.
And
yet,
when
we
tried
in
the
past
to
do
it
and
we
failed
to
paralyze
it,
and
there
were
a
variety
of
reasons
for
that.
Some
of
them
were
like
Microsoft's
compiler
at
the
time,
wasn't
compatible
with
something
else,
or
there
were
a
lot
of
annoying
issues
of
that
kind,
but
also
stamping
out
and
gaining
confidence
in
the
database.
B
So
this
has
actually
been
successful,
showing
speed
ups
and
that's
pretty
cool,
but
one
of
the
things
that
we
noticed
along
the
way
of
doing
all
this
work
for
multi-core
is
that
actually
that's
already
kind
of
a
little
bit
dated
in
terms
of
your
machine.
You'll
probably
have
four
to
eight
cores,
but
you
also
have
this
big
GPU
sitting
there
that's
doing
a
lot
more
parallelism
available
to
it.
B
So
one
of
the
other
big
projects
that
we
try
to
do
is
to
move
rendering
off
of
the
cores
and
onto
the
GPU
as
much
as
possible
and
following
in
the
model
of
day
engines.
This
is
actually
a
movie.
You
see
if
it
works,
so
this
is
showing
different
engine.
So
I
was
fifteen
nine
frames
per
second
five
frames
per
second
and
then,
when
we
get
the
servo,
we
come
to
sixty
frames
per
second
and
the
CPU
is
very
low.
B
B
B
See
not
that
I
know
of
but
I'm
actually
not
sure
it's
a
good
question,
but
a
lot
of
the
there's.
So
even
though
it
sounds
like
it's
all,
GPU
programming
there's
a
lot
of
support
that
goes
into
it.
So
all
the
code
around
it
is
all
in
rust.
In
short,
the
the
next
thing
I
wanted
to
talk
about
was
just
kind
of
what
rust
development
processes
like
and
the
community
of
rust
itself.
B
So
one
of
the
things
that
we've
worked
really
hard
on
and
probably
been
one
of
the
hardest
things
is
to
be
as
opening
as
open
and
as
welcoming
as
we
can
to
people
from
all
backgrounds,
and
that
means
both
technical
and
otherwise.
But
you
know
I
think
what
we've
been
a
little
bit
surprised
with
in
rust.
Is
we
expected
this
to
be
a
tool
for
C++
programmers
and
it
is,
to
a
certain
extent
right.
There
are
a
lot
of
C++
programmers
using
it
or
people
who
or
I
should
say
systems.
B
So
if
you
followed
rust
at
all
you
at
least
prior
to
the
1.0
release,
you
probably
noticed
at
least
one
thing
about
it,
which
was
that
we
changed
it
a
lot.
There
was
a
definitely
a
period,
so
I've
been
working
on
rust
six
years
almost
and
we've
been
two
years
of
stability
and
I
can
tell
you
that
before
that,
if
I
had
some
code,
that
was
six
weeks
old
I
would
just
erase
certain
ideas
notion,
it
was
not
going
to
compile,
is
going
to
be
a
lot
of
work
might
as
well
just
rewrite
it.
B
That's
exaggerating
a
little,
but
it
is
true
that
it
definitely
wouldn't
have
built,
and
we
had
to
do
is
because
we
were
doing
a
lot
of
experimentation,
finding
how
the
system
should
work
and
that
took
us
a
while,
and
so
when
we
declared
the
1.0
release.
We
definitely
wanted
an
end
to
that.
We
were
tired
of
it,
and
so
our
goal
is
basically
to
say
it's
not
that
will
never
change
rust,
but
that
it's
never.
B
You
will
never
be
afraid
to
upgrade
it
because
you
won't
have
a
hard
time
getting
your
code
to
compile
and
so
on,
and
so
we
can
maintain
compatibility
and
and
we'll
do
that
in
perpetuity
right.
But
the
danger
is
okay,
we're
going
to
maintain
compatibility,
can
we
keep
innovating?
Can
we
keep
improving
rust?
And
how
can
we
do
that?
And
so
we've
been
working
on
a
system
to?
Let
us
that
sort
of
lets
us
do
that
in
a
very
flexible
way,
and
we
call
this
our
kind
of
feature
pipeline.
B
So,
if
you
want
to
add
something
to
rust,
it
starts
out
in
the
RFC
phase.
Right-
and
this
is
this
is
true-
whether
you
are
in
the
rust
core
team
or
whether
you
are
somebody
who's
never
worked
in
rust
before.
If
you
have
some
cool
idea,
you
wanted
to
enjoy
rust,
you
write
up
a
description,
how
it
should
work-
and
you
put
it
up
on
our
RFC
repo
and
you
will
get
a
lot
of
feedback,
actually
probably
a
better
starting
point
before
you
post.
B
Not
only
is
it
discouraging
and
you
may
walk
away,
but
we
may
never
find
the
better
solution,
so
we're
always
looking
for
ways
to
kind
of
get
the
best
of
both
worlds
without
sacrificing,
if
that's
possible,
to
overcome
the
trade-off.
So
once
we
get
through
the
RFC
process,
we
move
to
this
nightly
release.
So
basically
the
Russ
compiler
is
kind
of
taking
a
model
from
browsers
here
until
we
release
more
or
less
every
night.
B
Sometimes
the
builds
don't
succeed
for
one
way
or
not
reason
or
another,
the
current
master
branch
and
you
can
use
that
and
people
do
and
then
you
basically
have
the
bleeding
edge.
So
that's
where
new
features
will
get
implemented
there
first
and
if
you
use
them
to
use
these
unstable
features
that
are
still
in
iteration,
you
have
to
opt
into
it.
In
your
code,
you
kind
of
declare
okay
I'm,
using
an
unstable
feature
here.
I
know
that
my
code
may
not
build
tomorrow.
B
B
B
When
we
see
we
feel
like
a
feature
is
done,
then
we
will
declare
that
it's
stable
and
it'll
go
on
to
the
stable
release
so
that
this
pipeline
has
served
us
pretty
well
for
letting
things
simultaneously
be
actively
developed
while
keeping
a
corset
stable.
We
also
do
a
lot
of
testing,
so
I
mentioned,
like
the
create
style
repository.
So,
for
example,
we
run
the
compiler
against
all
of
it
a
regular
basis,
checking
to
make
sure
everything
still
works,
the
same
as
it
used
to
and
so
on.
B
So
that
brings
me
to
roughly
the
end
of
my
talk.
I
want
to
leave
you
with
a
few
things.
First
off
there
is
a
bunch
of
resources.
If
you're
interested
in
rust,
we've
recently
completed
a
new
book,
which
I
think
is
very
exciting.
It
has
a
really
good
direction
for
learning
rust
and
covering
all
of
those
various
features.
We
have
a
users
mailing
list.
B
D
Thank
you
for
the
great
talk
I'm
interested
in
the
state
of
meta
programming
in
rust.
I
know
about
macros
they're
really
really
powerful,
but
they
are
not
namespaced,
for
example,
so
it's
hard
to
explore
them
between
kraid's.
Also,
there
are
no
very
addicts,
no
type
level
integers.
So
I
would
like
to
know
what
what
kind
of
work
is
being
done
in
that
direction,
because
something
that
I'm
passionate
about?
Yes,.
B
Meta
programming
is
I.
Imagine
something
a
lot
of
people
are
curious
about
so
yeah,
so
rust
has
two
main
directions
for
meta
programming,
so
you
mentioned
macros
I'll
kind
of
talk
about
the
two
things
first
separately,
so
the
current
macro
support
I,
don't
know
how
many
people
here
have
worked
in
scheme.
Any
me:
okay,
it's
very
similar
to
scheme
macros.
If
you
know
those-
and
particularly
macros
by
example,
two
are
very
powerful
and
they
let
you
of
write
arbitrary,
syntax,
essentially
inside
of
a
rust
code.
B
So,
however,
the
current
ones
they're
very
powerful,
but
they
also
have
a
lot
of
shortcomings,
so
the
name
spacing
was
one
there
are
others
too,
like
the
hygiene
support
is
lacking
and
so
forth.
So
we've
been
working
on
a
Mac,
what
we
call
macros
2.0,
which
is
basically
an
improved
version
of
the
macro
system.
It's
exactly
an
example
of
using
this
stability
system.
To
its
full
extent,
there
is
okay,
no
I
think
the
pr
is
not
yet
landed.
B
There
is
a
PR
with
the
initial
implementation,
but
of
this
macros
2.0
stuff,
that's
in
the
queue
and
will
be
coming
soon,
but
a
lot
of
the
namespacing
features
are
actually
already
there.
If
you
opt
in
on
a
feature
into
the
write
feature,
gate
I,
don't
know
the
name
of
top
my
head,
so
that
allows
you
to
basically
use
normal
imports
and
exports
to
name
macros
and
it
works
backwards,
compatible
with
the
old
macro
system.
B
We're
also
working
a
lot
on
procedural
macros,
which,
if
you
view
scheme
you're,
probably
familiar
with
so
macro
rules
that
I've
been
talking
about,
is
basically
like
a
interpreted
matching
language
that
lets
you
pull
out
things
and
paste
them
into
Russian
text
kind
of
like
handlebars,
but
different
I
mean
not
like
handlebars
at
all.
But
it
sort
of
looks
like
that
and
the
procedural
macros
is
really
you
just
write
rust
code,
it's
like
a
plug-in
and
the
compiler
will
invoke
that
code
and
execute
it
and
you
can
return
whatever
you
like
and
we've
stabilized.
B
The
first
version
of
these
which
we
call
derive
so
I,
didn't
talk
about
it
here,
but
you
often
have
these
traits
like
EQ
or
hash
they're.
Just
really
tedious,
to
write
for
your
structs
and
derive
is
basically
a
way
to
say,
run
this
code.
Here's
the
struct
definition
generate
automatically
a
reasonable
default
implementation,
and
now
that
used
to
be
built
into
the
compiler,
it's
now
something
you
can
write
in
a
Russ
code.
B
You
can
put
that
crate
on
crates,
IO
and
add
it
as
a
dependency
and
everything
kind
of
just
works,
and
so
that's
stable
now,
so
that's
macros
procedural
macros
are
coming
up,
I
should
say
they're
kind
of
part
of
the
same
macros
2.0
infrastructure,
because
it's
all
tied
into
the
hygiene
system.
As
for
other
meta
programming
right
now,
we
do
not
support
constant
generics
very
well.
However,
that
is
definitely
high
on
our
priority.
So
one
of
our
one
of
the
really
excellent
compiler
team
members,
Eddie
Burke
to
ski
I,
don't
actually
have
no
idea.
B
I
pronounce
his
last
name.
I
shouldn't
even
have
tried
Eddie
be
an
IRC
is
actively
working
on
it
and
I'm.
Confident,
therefore,
that
it
will
be
done
soon,
but
but
that
will
allow
us
to
kind
of
have
some
basic
support
and
we've
been
working,
honest
or
advanced
support
as
well,
but
I.
Think
extending
the
trade
system
is
something
that
we
are.
B
You
have
a
lot
of
ideas,
and
one
of
the
big
projects
we're
doing
besides
concentrates
is
actually
reformulating
the
trade
system
in
a
more
formal
way,
because
we
found
that
the
current
system-
it's
like
it's
time
for
us
to
have
a
kind
of
more
core
expression
of
it,
so
that
we
can
better
understand
all
these
extensions
like
specialization
and
so
on.
So
a
lot
of
things
you
can
do
in
C++
generics
that
you
can't
necessarily
do
in
rust.
Yet
what
we
do
aim
to
support
them.
Cool.
D
C
Thanks
for
the
talk,
and
so
in
crime
grass
on
rust
being
stable
for
two
years,
that's
cool
input.
Bus
has
been
there
for
arguably
ting
twenty
and
thirty
years,
and
what
seems
to
have
happened
is
over
time.
Probably
when
two
years
after
C++
had
this
kind
of
like
stability,
they
thought
that
it
was
pretty
much.
Everything
was
a
good
idea
that
was
their
plus
twenty
to
thirty.
Three
years
later
turns
out.
There
are
better
ideas
and
incorporating
the
better
ideas
and
maintaining
backwards.
Compatibility
is
incredibly
hard,
especially
if
you
want
to
do
an
elegant
way.
C
B
Good
question:
that's
actually
a
topic
of
hot
discussion.
Not
surprisingly,
we've
been
talking
about
I
should
say
here,
I'm
going
out
on
a
limb
because
I'm
these
things
are
not
settled
by
any
means,
but
the
way
that
I
see
this
happening
is
we've
been
discussing,
introducing
something
which
we
call
a
pox,
which
just
kind
of
corresponds
to
like
C++,
eleven
plus
fourteen
sore,
in
a
sense
that
these
would
be
essentially
different
kind
of
like
different
versions
of
the
rust
language.
B
But
the
compiler
would
continue
to
compile
the
older
code
and
we
would
gradually
transition
from
one
to
the
other.
But
when
you
move
to
the
new
epoch,
essentially
a
whole
bunch
of
deprecated
things
become
errors
all
right,
so
we
would
be
trying
to
phase
out
things
that
we
don't
want,
and
sometimes
that's
just
because
we
think
it's
an
anti-pattern.
Sometimes
it's
because
we
think
that
it's
we
want
to
make
room
for
a
better
way
of
doing
it.
And
to
do
that,
we
have
to
kind
of
first
make
the
old
stuff
go
away.
B
We
can't
we
don't
want
to
break
any
existing
code.
So
the
idea
is
that
packages
that
are
up
there
will
they
have
no
add
back.
They
will
default
to
let
the
oldest
one
and
they
will
continue
to
compile
as
they
ever
did,
and
they
should
be
completely
inter
compatible
with
new
packages.
Because
of
all
these
changes
tend
to
be
kind
of
in
the
syntax
level.
B
Let's
say,
and
you
can
usually
at
least
we
would
not
want
to
do
any
changes
that
don't
allow
you
to
communicate
with
older
code
in
any
way
like
they
really
changed
the
representation
or
something
somebody
that's
not
backwards
compatible
at
all.
But
this
would
allow
us
to
kind
of
deprecated
older
styles
of
code
that
we
think
features.
B
Do
you
think
people
shouldn't
be
using
and
make
room
for
newer
things,
but
we're
still
discussing
it
I
mean
there's,
definitely
a
concern
that
perhaps
the
message
becomes
too
subtle
of
stability
and
people
are
afraid
that
they
don't
want
to
upgrade,
because
they
think
that
it
will
break
their
code
and
so
forth.
So
we
have
to
make
sure
that
it's
understood
you
know,
but
in
fact
all
the
old
code
keeps
working.
The
world
is
not
split.
Your
dependencies
don't
have
to
upgrade
just
because
you
did
and
things
like
that.