►
From YouTube: Rust: Safe and Scalable Systems Programming
Description
Speaker: Alex Crichton - Senior Research Engineer, Mozilla
Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. Modern language features, such as closures, type inference, pattern matching, and trait-based generics, are supported in tandem with low-level features like zero-cost abstractions, efficient C bindings, and a minimal runtime. With the stable 1.0 release of the language in May 2015 Rust has seen widespread growth and adoption as well as continuous iteration on both the language and the libraries. This talk will explain the fundamentals of Rust and how they're leveraged to achieve the language's lofty goals as well as give a preview of some of Rust's upcoming features.
Alex is a Senior Research Engineer at Mozilla since late 2013. As a member of the Rust core team, library team, and leader of the Tools team, Alex has been working on Rust since late 2012. He is the author of the current std::sync::mpsc module in the standard library, and in the past has architected the runtimes of the standard library (which have since been removed). Currently Alex works on Cargo, Rust's package manager, the standard library, and fostering development of libraries in the community at large.
Recorded at Big Techday 9 / http://www.bigtechday.com of TNG Technology Consulting GmbH / http://www.tngtech.com on June 3rd, 2016 in Munich / Germany
A
Now
it
is
so
first,
let's
talk
about
what
rust
is.
If
you
take
a
look
at
our
website,
you'll
see
the
soundbite
saying
that
rust
is
assistance.
Programming,
language
that
runs
blazingly
fast,
prevents
nearly
all
site
faults
and
guarantees
thread
safety.
Those
are
some
pretty
lofty
goals
for
this
one
language
to
be
doing.
It
also
claim
that
it's
a
systems
language
all
at
the
same
time,
so
I'm
going
to
kind
of
break
this
down
and
what
kind
of
see
as
we
go
along
how
it
can
actually
guarantee
all
these
really
nice
properties.
A
But
first,
let's
take
a
look
at
the
existing
language
landscape.
You
query:
in
the
kind
of
area
of
systems
primary
languages,
we
can
typically
graph
it
on
these
two
axes
of
control
versus
safety
or
on
one
end,
we've
got
C
and
C++.
These
languages
are,
unfortunately,
very
unsafe.
They
have
a
lot
of
memory
safety
problems.
You
can
get
memory,
corruption
and
use
after
freeze
double
freeze.
All
this
all
these
crazy
things
which
cause
things
like
heartbleed
or
cause
various
security
vulnerabilities
and
like
web
browsers.
A
But
on
the
other
hand,
they
give
you
this
really
high
degree
of
control,
that's
very
hard
to
find
elsewhere,
and
this
allows
you
to
write
the
fastest
kind
of
program
of
that.
You
actually
want
you've,
a
very
direct
translation
when
you
see
C
and
C++.
So
what
assembly
is
actually
running,
what's
actually
running
on
the
machine
itself
and
that's
why
these
are
so
popular
nowadays.
A
But
as
we
move
along
here,
we'll
see
kind
of
another
group
of
languages
somewhere
in
the
middle
things
like
go
or
Java
or
Scala
and
the
defining
feature
of
these
languages
are,
they
have
a
lot
of
very
large
garbage
collector,
and
so
this
garbage
collector
is
going
to
give
you
a
much
higher
degree
of
safety
than
C
in
C++.
You
don't
have
to
worry
about
use
after
freeze,
you
don't
have
to
worry
about
memory,
corruption,
it's
all
entire
class
of
bugs
have
all
been
erased,
but
at
the
other.
A
A
So
we're
kind
of
moving
down
the
level
of
control,
but
we're
increasing
safety
at
the
same
time,
and
if
we
go
even
farther
we'll
see
the
languages
like
Haskell
Haskell,
give
you
a
ton
of
safety,
hey
hey,
let's
get
it's
kind
of
the
whole
underpinnings
of
it,
but
at
the
other
hand
its
Haskell
is
a
very
lazy
language.
So
it's
very
difficult
to
actually
reason
about
the
runtimes,
the
level
of
control
you're
getting
over.
What
you
would
expect
from
C
and
C++
is
much
less.
A
When
you
think
of
low-level
today,
you
think
of
C
and
C++
in
like
al-azhar,
unsafe
I'm,
not
actually
going
to
use
those
I
have
to
be
a
serious
guru.
Wizard
to
actually
be
able
to
use
that
and
rust
is
saying
we
can
actually
reverse
that
a
little
bit.
Rust
itself
is
a
very
low-level
language,
but
it's
also
safe
low
level.
No
longer
just
means
I
can't
use
it.
It
is.
This
is
too
difficult
for
me,
so
rust
is
kind
of
packaging.
A
All
these
up
and
kind
of
one
nice
bundle
for
you
to
take
a
look
at.
So
why
would
you
might
be
interested
in
rust?
I?
You
may
not
always
be
interested
in
C++,
but
so
with
rust.
They're
kind
of
there
are
two
big
use:
cases
of
you're
already
doing
systems,
programming,
you're
already
hacking
around
and
C
and
C++.
But
you
don't
really
like
having
to
worry
about
all
these
memory
safety
issues.
You
don't
really
like
having
to
kind
of
constantly
read
bug
reports
step
through
debuggers.
Have
these
crazy
crashes?
A
You
don't
really
know
what's
going
on,
but
so
you
want
that
level
of
safety
or
you
just
want
some
more
modern,
modern
languages.
You
would
expect
remote
from
a
language
modern
features
from
a
language
that
was
produced
in
about
2015
or
2016,
but
on
the
other
hand,
you
might
also
be
a
very
high
level
developer,
you're
working
in
JavaScript
or
Ruby
or
Python,
and
you
want
this
level
assistance
programming.
You
have
these
tight
loops
and
you
want
to
run
a
lot
faster,
but
you
can't
do
that
in
your
source
language.
A
So
you
need
the
control
of
c
plus
c
and
c++,
but
you're
very
intimidated
to
actually
go
down
to
that
level.
So,
with
rust,
you
can
kind
of
retain
the
safety
contracts
of
your
original
language,
while
also
going
down
and
enabling
to
have
a
much
faster
implementation
that,
like
you,
would
get
in
C
and
C++,
and
next
thing
I'd
be
wondering
is
why
is
Mozilla
doing
this?
A
A
This
is
a
language
that
can
solve
these
problems,
and
you
can
actually
see
this
in
vision
in
a
new
web
browser
coming
out
of
Mozilla
research
called
servo
and
servo
is
actually
a
reimagining
of
kind
of
rendering
engines
where
it's
not
only
writing
a
new
engine
and
C
in
rust.
But
it's
also
adding
new
concepts
are
very,
very
difficult
to
plant
C++
today,
the
biggest
one
being
parallelism.
This
is
experimenting
with
parallel
layout
of
web
pages,
which
see
massive
performance
improvements
so
far.
A
But
if
you
were
try
and
retrofit
this
on
the
existing
engine
code
gecko
inside
of
Firefox,
it
would
be
multiple
man
years
of
effort
if
you
could
even
get
it
done,
and
even
at
that
point
you
would
have
no
idea
that
it's
actually
safe,
because
it's
so
difficult
to
understand
all
the
interactions
between
all
the
C++
components.
So
servo
itself
is
kind
of
its
own.
A
A
So
if
we
kind
of
zoom
in
we'll
see
that
these
elements
of
the
array
themselves
have
a
data
length
and
capacity
pointer
with
the
data,
then
points
to
a
list
of
bytes
on
the
edge.
But
the
key
thing
here
is
everything
is
laid
out
in
line
there's
kind
of
no
extra
layers
of
indirection.
You
have
very
fine-grained
control
and
if
you
were
to
write
this
all
by
hand,
you'd
probably
do
it
almost
exactly
like
that,
and
the
next
thing
we'll
see
in
C++
are
these
lightweight
references.
A
This
little
pointer
is
actually
just
a
raw
pointer
in
memory
pointing
directly
at
the
first
element
on
the
vector-
and
this
is
nice,
because
there's
no
extra
tracking
metadata
there's
no
extra
fluff
around
this.
All.
It
is
just
a
pointer
straight
in
memory.
Just
this
raw
pointer
sitting
around
will
see
some
problems
with
that,
but
it's
very
nice
in
terms
of
cost.
It's
very
lightweight,
it's
very
easy
to
work
with,
and
the
final
thing
that
gives
us
a
lot
of
control
in
C++
is
this
idea
of
deterministic
destruction.
A
We
know
that
this
vector
of
strings
is
owned
by
this
example
function.
So
as
soon
as
this
function
returns,
we
know
that
we
can
D
a
locator.
We
can
free
all
the
resources
associated
with
it.
We
can
destroy
all
the
internal
strings
themselves,
and
that
gives
us
a
lot
of
power
actually
knowing
when
our
resources
are
going
to
be
de-allocated
a
lot
of
these
lot
of
what
these
concepts
boil
down
to
or
what
we
call
zero-cost
abstractions
and
that's
basically
a
fancy
way
of
saying.
A
If,
if
you
were
to
write
this
all
by
hand,
you
would
all
you
would
do
exactly
what
the
compiler
was
already
generating,
which
is
that
all
this
stuff,
you're
writing
just
compiles
down
to
nothing
and
the
compiler
will
just
rip
through
everything
in
Tortola
way
and
the
economy
you'll
be
running
at
the
lowest
level
that
you
that
you
would
have
done
anyway.
If
you
were
writing
the
assembly
yourself
and
as
a
counterexample
to
this,
we
can
take
a
look
at
java.
A
So
if
we
have
the
same
vector
of
strings
in
Java
Java
has
this
restriction
where
all
the
values
are
word
size.
So,
instead
of
our
vector
being
these
three
pointers,
we're
actually
going
to
have
our
vector
being
a
planer
into
some
data,
which
then
has
the
data
pointer
and
then
all
the
elements
of
the
vector
itself
are
then
another
pointer
which
has
been
pointing
the
more
data,
and
we
can
see
here
there's
extra
layers
of
indirection
going
on
here.
This
is
not
as
compact
as
C++.
A
If
you
wanted
to
write
this
as
fast
as
possible,
you
would
probably
wouldn't
write
this,
and
this
is
just,
unfortunately,
a
limitation
of
the
language
itself.
It's
very
difficult
to
overcome,
without
actually
going
to
another
language
or
kind
of
dropping
down
to
another
level,
and
this
is
subtraction,
doesn't
only
apply
to
memory
layout.
This
is
also
things
like
static
dispatch
and
template
expansion.
Where
you
want
to
know
when
you're,
actually
writing
some
code
and
running
it,
is
it
going
to
be
virtually
dispatched?
Are
you
going
to
kind
of
running
it
directly?
A
Are
you
be
generating
tons
of
code
or
you'll
be
generating
this
little
small
amount?
That's
very
generic,
but
a
little
bit
slower
at
the
cost
of
runtime.
So
having
this
control
and
having
this
knowledge
of
what's
actually
happening
under
the
machine,
is
kind
of
what
these
zero
zero
cost
abstractions
are
all
about.
A
So
next
thing
is:
let's
take
a
look
at
this
safety,
so
here
we
have
our
previous
example
of
a
vector
of
strings
in
the
stack.
We're
gonna
take
a
pointer
into
it,
but
then
we're
going
to
kind
of
have
a
few
problems
that
go
along
as
well.
So
well
after
we've
taken
this
pointer,
we're
now
going
to
push
a
new
string
under
this
vector.
A
Now
those
of
you
who
have
implemented
vectors
before
know
that,
if
your
vectors
run
out
of
space,
you
got
to
reallocate
it
copy
it
around
and
then
add
the
new
element
onto
it.
So
what
this
is
going
to
do
or
what
it
might
be
it
might
do,
is
it'll
allocate
some
new
memory
with
a
couple
more
slots
it'll
copy
over
the
existing
data.
In
this
case,
just
the
first
string
it'll
then
add
on
our
new
string,
but
the
key
thing
here
is,
after
we've
done
all
that
we're
going
to
deallocate
our
previous
allocation.
A
So
this
previous
slot
of
just
the
first
string
is
now
gone
and
we
as
the
vector
have
now
updated
our
data
pointer
because
we're
correctly
tracking
it
we're
going
to
make
sure
it's
alright.
But
as
we
can
see
here,
we
have
this
dangling
pointer
in
the
freed
memory.
This
is
going
to
be
a
serious
problem
once
we
come
around
and
try
and
print
it
probably
going
to
get
some
weird
garbage
to
the
console,
or
hopefully
we'll
get
a
psych
fault
if
we're
lucky.
A
But
this
is
all
this
is-
might
be
kind
of
difficult
to
debug
kind
of,
depending
on
the
situation.
We
actually
see
this
in
and
it's
kind
of
beneficial,
that's
kind
of
a
contrived
bug
and
you'll
see
a
lot
of
these
in
C
and
C++,
and
you
can
kind
of
situation
solve
many
of
these.
But
what
we
really
want
to
do
is
look
at
the
fundamental
ingredients
of
what
happened
here.
A
Why
did
this
bug
come
up,
and
how
can
we
prevent
this
just
across
the
board
entirely
and
it
turns
out
you
can
break
this
down
in
a
few
ingredients.
The
first
one
here
we
have
is
aliasing,
so
this
data
pointer
and
this
element
pointer
that
we
had
earlier
will
point
to
the
same
piece
of
memory.
So
these
two
pointers
are
aliasing
and
we're
going
to
have
these
problems
once
we
try
and
update
one
of
them,
but
we
don't
update
the
other.
A
Well,
if
I
kind
of
be
seeing
that
a
lot
in
the
rest
of
the
talk
of
what's
happening
once
we
have
mutation
and
aliasing
and
kind
of
how
rust
is
helping
you
with
this
and
something
like
thinking,
okay.
Well,
what
about
a
garbage
collector?
This
is
exactly
what
garbage
collectors
are
trying
to
solve.
We
have
all
this
aliasing
lying
around.
We
can
update
some
pointers.
We
know
exactly
how
to
do
this,
but
garbage
collectors
come
with
some
downsides.
Those
were
just
looking
at
earlier.
A
Garbage
collectors
give
you
less
control
than
what
you
would
expect
you
have.
These
indeterminate
GC
pauses,
it's
kind
of
tough
to
know
when
these
things
are
going
to
go
out
of
scope.
So
you
don't
know
when
the
when
resources
are
going
to
be
de-allocated,
and
then
one
thing
you
often
forget,
when
you
think
about
a
garbage
collector
is
it
requires
a
runtime.
This
is
a
pretty
serious
thing
sometimes.
A
You
can
put
a
C
library
in
your
Ruby
application
and
work
just
fine,
but
you
don't
really
often
hear
about
taking
your
Ruby
application
and
putting
it
inside
of
a
java
application,
and
that's
typically
because
the
two
garbage
collectors
are
not
going
to
play
nicely
with
one
another
so
having
this
runt
having
to
require
one
time
ends
up
being
somewhat
of
a
serious
downside,
but
then
not
only
this,
but
GC
doesn't
solve
a
lot
of
related
problems.
So
if
you've
ever
seen
a
concurrent
modification
exception
in
Java.
This
is
the
iterator
invalidation
problem.
A
If
you've
ever
seen
a
data
race
in
C
and
C++
or
just
concurrency
problems
in
Java,
this
is
also
a
problem
that
garbage
collection
doesn't
solve,
and
these
are
things
that
we
are.
We
in
rust
are
very,
very
interested
in
solving,
and
so
our
solution
to
this
is
not
so
much
that
garbage
collector
brother,
two
concepts
that
we
call
ownership
and
borrowing.
So
these
are
the
core
fundamentals
of
rust,
which
essentially
everything
else
blossoms
out
of
and
ownership
and
borrowing
gives
us
these
kind
of
really
awesome
properties
of
we
don't
need
a
runtime.
A
This
is
purely
a
static
analysis
that
happens
at
compile
time,
so
it
doesn't,
has
no
cost.
It's
completely
zero
costs,
and
this
is
the
derivative
source
for
all
of
our
memory.
Safety
you'll
see
I'll
kind
of
give
you
some
examples
of
how
these
two
are
preventing
these
bugs.
We
were
seeing
in
C
and
C++
and
finally
we're
getting
this
guarantee.
We
don't
actually
have
any
data
races.
Ross
is
a
language
that
doesn't
have
any
data,
races
and
concurrent
programming.
A
That's
a
really
really
powerful
thing
really
actually
card
kind
of
hard
to
find
that
other
languages
nowadays.
So
we
take
a
look
at
this
in
C++.
We
have
no
need
for
a
runtime,
that's
kind
of
a
great
reason
that
you
would
use
C++.
It's
embeddable.
You
can
throw
it
anywhere,
but
you
don't
have
this
memory
safety.
You
don't
have
this
database
freedom
and
with
garbage
collection.
We
have
memory
safety,
but
then
we
have
a
runtime
and
we
still
don't
get
this
database
for
you.
A
So
we
can
see
how
these
concepts
of
ownership
and
borrowing
or
actually
end
up
benefiting
us
quite
a
bit
by
giving
all
these
benefits
simultaneously
and
in
rust.
You'll
also
find
a
lot
of
other
fun
language
features.
So,
for
example,
you
have
pattern
matching
which
has
been
tried
and
true
and
proven
many
other
functional
languages
nowadays,
you'll
have
smart
pointers.
A
So
if
you
you'll
see
this
a
lot
in
C++
where
you,
the
standard
library,
doesn't
necessarily
give
you
all
the
abstractions
you
want,
so
you
can
kind
of
build
up
your
own
and
can't
have
your
own
little
thin,
shims
around
and
also
stuff
like
if
you're
familiar
with
Ruby
and
the
bundler
package.
Manager'
rust
comes
with
cargo
of
the
a
very
similar
concept
which
allows
you
gives
you
access.
The
entire
ecosystem
of
rust
code
essentially
instantaneously.
A
A
So
I
want
to
kind
of
start
diving
into
what
I
mean
by
ownership
and
what
I
mean
by
borrowing
I'm
going
to
kind
of
give
you
a
high-level
view
of
what
these
are,
how
it
applies
in
rust
and
then
we'll
also
take
a
look
at
kind
of
how
it
actually
enables
us
to
give
you
the
safety
and
concurrency,
and
we
can
eliminate
eliminate
all
databases,
so
ownership
basically
just
means
kind
of
what
the
word
actually
means.
I
is
the
owner
of
resource
I
own.
A
This
book
I
can
then
decide
to
kind
of
give
this
book
to
someone
else.
I
pass
ownership
to
them.
I
can
then
go
away.
That
resource
is
fine.
They
own
that,
but
once
the
owner
of
the
resource
goes
away,
we
know
this
resource
is
not
owned
by
anyone
else.
So
this
is
the
time
where
we
can
actually
just
destroy
it.
We
can,
we
can
worry
about
it.
A
We
can
do
like
eight
everything,
so
I
was
talking
earlier
about
how
aliasing
mutation
are
these
two
simultaneous
concepts
that
we
have
to
prevent
having
these
at
the
same
time
as
this?
First
of
all,
these
a
lot
of
member
safety
bugs
in
C
and
C++,
so
as
with
ownership,
you'll
see
that
we're
going
to
be
preventing
aliasing
we're
going
to
allow
mutation
through
it,
but
we're
preventing
this
one
key
ingredient
to
all
these
bugs,
and
so
looking
at
this
in
rust.
A
We'll
have
a
simple
example:
where
we're
just
going
to
make
a
vector
on
the
stack,
we're
going
to
push
some
elements
onto
it
and
then
pass
it
over
somewhere
else.
So
you
notice
immediately
that,
like
in
C++,
rust,
is
storing
this
vector
directly
on
the
stack
we've
got.
The
date
of
the
length,
length
and
capacity
pointer
is
just
stored
directly
in
line
we're
going
to
put
some
data
out
of
it.
So
push
a1,
then
we'll
come
around,
we'll
push
it
to
again
we'll
see.
A
This
is
right
next,
in
line
there's
no
extra
layers
of
indirection
here.
This
is
kind
of
a
zero
cost
abstraction
in
play
and
then
we'll
come
along
to
actually
calling
this
function
where
we're
going
to
pass
other
ship
of
this
vector
and
the
way
we
know
that
when
we
take
a
look
at
this
type,
signature
will
see
that
this
VEX,
just
this
bare
Beck
of
integers,
that
indicates
that
this
function
is
taking
ownership.
A
It's
going
to
consume
it
from
the
caller
and
it's
going
to
have
access
to
it
internally
and
what
that
actually
means
at
runtime
is
we're
going
to
create
a
shallow
copy
of
this
vector,
so
we're
going
to
copy
this
data
length
and
capacity
pointer
to
pass
to
the
take
function,
so
we
can
have
access
to
it,
but,
as
you
can
see,
there's
some
aliasing
about
going
on
here.
So
the
key
aspect
of
this
is
that
the
give
function
is
going
to
forget
its
own
copy.
A
It's
going
to
say:
I,
don't
want
to
have
access
to
that
I.
All
of
the
ownership
of
this
data
has
now
passed
off.
To
take
so
take
is
going
to
start
running.
It
can
kind
of
do
whatever
it
wants
to
the
vector
and
by
the
time
it
gets
to
the
end.
We
know
from
ownership
that
this
is
the
only
place
where
you
can
actually
access
the
vector.
So
it's
time
to
delegate
free
the
resources,
make
it
all
go
away,
and
then
we
can
come
along
back
to
the
function,
give
and
run
along
our
merry
way.
A
So
you
might
be
thinking
all
right,
that's
all
fine
and
dandy,
but
what
happens
if
I
actually
try
and
use
this
vector
F
after
we
pass
take
what
are
like
a
running
some
extra
code
here?
What
if
we
accidentally
try
to
use
this
freed
memory
so,
for
example,
what
if
we
just
tried
to
push
some
more
data
onto
it
after
was
freed
after
it,
and
what
the
compiler
is
going
to
tell
you
is
like
no.
This
vector
has
been
moved
at
this
point.
A
The
function
called
a
take
was
where
you
move
the
vector
to
the
function,
call
to
the
actual
function
take,
and
so
it's
been
dated
after
that.
So
this
is
going
to
be
disallowed
as
compiler
error,
you
can't
use
anything
after
you
can
moved
it
out
to
someone
else.
Almost
I
kind
of
give
you
back
on
our
ship
and
what
this
ends
up,
meaning
is
that
we
can
prevent
these
quite
entire
classes
of
bugs
you
see
in
C++
use
after
fries
or
double
moves
or
anything
related
to
all
of
this.
A
A
So
this,
this
concept
of
borrowing
is
kind
of
just
I'm,
going
to
allow
you
to
use
this
for
a
small
period
of
time
and
in
rust
we
have
two
kinds
of
borrows,
the
first
of
which
we
call
shared
borrow
in
this
case.
I
is
the
owner
of
resource
I
can
take
out
a
shared
borrow
and
then
I
can
also
take
that
share,
borrow
and
pass
it
to
a
couple
other
users.
A
At
the
same
time,
these
could
be
threads
or
function,
calls
or
data
structures
or
whatever
you
like,
but
the
key
thing
is,
you
can
have
multiple
shared
borrows
at
once
implied
by
the
name
share.
So
again,
these
two
ingredients
of
aliasing
mutation
we've
seen
that
if
a
share
borrows
we're
going
to
have
aliasing,
so
we're
going
to
disallow
mutation
through
shared
borrows,
but
that
wouldn't
be
very
good
if
we
only
could,
if
you
can't
actually
mutate
things
through
borrows.
So
our
second
kind
of
borrow
that
we
have
in
rust
is
called
a
mutable
borrow.
A
An
immutable
borrow
happens
when
the
owner
of
resource
decides.
This
decides
to
loan
out
on
Google
ro.
You
can
hand
it
out
one
at
a
time
and
then
I,
as
the
owner
of
a
current
people,
borrow
then
decide
to
pass
it
along
to
someone
else.
This
kind
of
travels
down
the
stack
and
then
once
everyone
starts
returning
ownership
of
this
resource
still
retains
with
the
original
owner.
So
this
mule
borrow
is
passing
on
back
up
the
stack
and
eventually
is
going
to
come
back
to
the
original
owner
and
I'll
fill
in
the
data
again.
A
So
these
two
ingredients
of
a
listing
mutation
we've
seen
that
meet
Alvaro's
are
going
to
allow
allow
mutation,
so
we're
going
to
be
disallowing
aliasing
from
these
mutable
borrows,
so
they
can
take
a
look.
At
example,
what's
going
on
here?
Well,
this
is
the
same
example
from
before,
where
you
create
a
vector,
push
some
data
onto
it
and
pass
it
off.
So
I
have
the
same
situation
where
the
vector
two
data
points
on
it,
but
the
difference
happens
when
we
actually
call
this
function.
A
This
little
ampersand,
sigil
in
front
of
the
vector
means
that
this
is
a
shared
reference
to
a
vector
of
integers,
and
then
this
little
ampersand
sigil
at
the
call
site
means
that
I'm
taking
a
loan
out
on
this
vector
temporarily
and
what's
what
that
saying
is
like?
We
just
saw
the
word:
Veck
I'm,
not
actually
passing
ownership
of
this
I'm
only
passing
Temper
a
temporary
borrow
through
the
actual
function
call
and
at
runtime.
What
this
is
is
kind
of.
A
We
can
still.
We
can
then
mutate
it.
We
could
add
more
things
onto
it.
We
could
send
out
a
borrow
someone
else
and,
as
I
was
saying
earlier,
with
shared
borrows,
you
can't
mutate
through
this.
So,
for
example,
the
use
function
is
law
earlier.
You
can't
push
some
more
elements
onto
it.
You
can't
modify
existing
elements.
These
are
both,
but
both
going
to
be
disallowed
by
the
compiler
and
the.
The
summary
of
that
is
basically
that
you
you
share.
A
Reference
is
almost
always
read-only,
there's
some
caveats
here
where
there
we
do
actually
allow
some
mutation
and
controlled
circumstances
and
we'll
see
some
examples
of
that
a
little
bit
later
in
the
talk.
But
this
is
some
it.
Suffice
it
to
say
that
when
you
see
a
shared
reference,
you
can
think
immutable,
and
it's
only
read-only
at
that
point.
A
Let's
go
mutable
references
are
also
producing,
so
here's
just
a
simple
function,
where
we're
going
to
take
a
bunch
of
items
for
one
vector
and
just
push
them
on
to
another
vector,
so
our
from
an
r2
and
this
little
ampersand
mute
is
what
means
that
this
is
a
mutable
reference
to
a
vector
of
integers
and
how
it's
going
to
push
things
on,
and
because
we
have
this
single
reference.
We're
actually
going
to
be
able
to
push,
unlike
we
could,
before
with
the
shared
reference.
A
So,
taking
a
look
at
the
at
the
runtime
of
this,
we
have
our
front
pointer,
which
is
going
to
have
the
elements
one
two
and
three
immigrants
umar
two
vectors
empty
empty
just
so
far,
so
we're
going
to
try
and
push
this
one
two
and
three
on
there,
so
we're
going
to
start
up
our
for
loop,
and
this
is
the
way
that
elements
actually
working.
Is
it's
just
a
raw
pointer
memory
again
to
just
the
one
two
three
elements
of
the
front
loop
from
the
from
loop
itself
so
like
before?
A
That's
just
a
raw
pointer
or
no
extra
metadata
tracking.
It's
just
a
thin
reference
to
that.
So
the
first
thing
we're
going
to
do
is
push
the
push.
The
one
on
to
the
on
to
the
two
vector
will
kind
of
turn
the
loop
again
and
a
key
thing
that's
going
to
happen
here
is
this
is
just
a
very
simple
iterator
over
the
vector.
So
it's
a
pretty
simple
operation.
We
do
now
just
little
pony
arithmetic.
All
we
do
is
swing.
A
This
pointer
from
the
first
element
down
to
the
second
element
and
I,
can
push
that
and
keep
on
going
at
the
loop
until
we
push
everything
now.
Some
of
you
who
might
have
seen
this
before
or
kind
of
implements
on
this
in
C
and
C++
might
say
what.
If
these
two
vectors
are
the
same
thing:
what
if
the
from
vector
and
the
two
vector,
actually
referenced
the
same
underlying
vector
so
like
we
saw
on
the
first
slide
once
we
push
an
element,
we
might
have
to
reallocate
the
vector
and
copied
out
elsewhere
memory.
A
So
let's
say
this
push
operation,
where
we're
trying
to
push
one
under
the
same
vector
does
exactly
that.
So
we
copy
over
our
one
two
and
three
over
to
the
new
vector
we
push
one
onto
it,
but
we've
D
allocated
the
previous
contents.
Now
the
bad
part
is
going
to
happen
here
once
we
try
and
turn
the
loop
again
we're
going
to
swing
this
element
pointer
down
to
the
second
element,
but
that's
now
a
dangling
pointer
in
free
memory.
We
don't
longer
have
any
access
to
that
memory.
A
It's
buddy
allocated
its
and
use
by
someone
else.
This
is
essentially
a
seg
fault,
so
we
take
a
look
at
how
this
might
actually
happen
in
rest.
This
is
our
push
off
function,
but
from
before
just
pushing
from
from
on
the
two,
and
this
is
how
we
might
try
and
call
it
will
create
a
vector
and
then
we'll
try
and
actually
call
the
push
off
function
itself
and
what
the
compiler
sees
here
is.
A
Okay,
first
thing:
I'm
going
to
do
is
take
out
a
shared
reference
and
I
as
the
compiler
know
that
this
the
shared
reference
has
to
last
for
the
duration
of
the
push
all
function,
so
I
have
to
kind
of
keep
it
alive
for
this
entire
time.
So,
by
the
time
we
come
around
to
this
mutable
reference,
the
kamala
says:
okay,
well,
I
can't
have
both
a
shared
and
a
mutable
reference
at
the
same
time.
So
it's
going
to
be
disallowed.
A
A
So
this
is
all
this
is
going
to
be
rejected
by
the
compiler
and
ends
up
having
a
pretty
nice
property
of
mutable
pointers,
where
this
means
that,
if
you
have
ampersand
mutti,
that's
the
only
way
to
access
the
memory
points
that
you're
guaranteed
that
no
one
else
is
concurrently
accessing
this
and
it's
not
stored
in
any
digit
structure.
It's
not
kind
of
off
in
the
weeds
somewhere.
A
You
have
the
only
way
to
access
that
piece
of
memory,
and
this
ends
up
being
a
really
powerful
property,
not
only
in
terms
of
what
the
compiler
can
do
in
terms
of
optimizations,
but
also
in
terms
of
how
you
can
reason
about
how
you
can
understand
if
I
have
an
ampersand
beauty.
Well,
what
can
I
do
with
it
or,
if
I'm
handing
off
one
kind
of
what
powers
am
I
lending
this?
This
function
that
I'm
calling
to
actually
be
able
to
do
with
that
memory?
A
So
this
might
seem
kind
of
weird
like
okay,
I
can't
have
I
can
have
shared
references
like
I
and
mutable
references,
but
I
can't
have
them
at
the
same
time.
How
am
I
going
to
juggle
this?
All
I'm
gonna
have
to
have
all
these
weird
annotations
everywhere,
but
it
turns
out
that
rust
also
has
this
concept
of
lifetime's,
where
it's
kind
of
keeping
track
of
the
length
of
these
borrows
over
time.
So
in
this
example,
we
create
a
vector
we're
going
to
iterate
over
it,
take
a
reference
and
try
and
mutate
it.
A
But
clearly
this
is
very
bad.
If
we
cuz,
we
can't
have
a
reference.
What
we
then
mutated
at
the
same
time
and
the
way
rust
understands
this
is
once
we
try
and
do
the
push.
We
know
that
this
borrow
this
original
borrow
from
the
Veck
of
I
is
alive
for
the
entire
scope
of
this
for
loop.
So
this
element
pointer
is
kind
of
alive
during
that
entire
scope.
A
So
we
know
that
the
borrow
is
active
for
that
entire
scope
and
then,
while
that
borrow
is
active,
you
can't
take
out
a
mutable
reference,
so
this
is
going
to
be
disallowed.
The
compiler
says
that
the
the
vector
is
already
borrowed
for
this
period
of
times
like
I,
can't
any
allow
any
other
borrows
during
this
time.
A
But
on
the
other
hand,
it
understands
that
once
you
come
out
of
the
for
loop,
you've
exited
out
of
that
scope,
and
you
can
actually
now
take
a
butyl
reference
again,
so
you're
allowed
to
kind
of
once
all
references
have
gone
out
of
scope.
You
can
then
continue
to
take
more
references
or
more
borrows
out
on
an
element
all
right,
so
that's
kind
of
borrowing
and
ownership
in
a
nutshell,
kind
of
how
rust
does
that,
how
rust
uses
it
and
how
you
might
be
able
to
use
it
internally.
A
So,
let's
take
a
look
at
exactly
what
happens
when
we
try
and
apply
this
to
concurrency
and
how
we
can
solve
this
database
problem.
We
saw
earlier
and
rust
actually
has
a
pretty
interesting
concurrency
story
over
time.
In
the
ye
olden
days,
we
had
only
had
message
passing.
That
was
the
only
way
we
figured
that's
a
pretty
simple
way
to
reason
about
concurrency
and
we'll
just
kind
of
have
that
and
I
will
suffice
for
everyone,
but
over
time,
as
a
systems,
programming
language
we
ended
up
realizing
that
we
actually
need
to.
A
There
are
many
other
paradigms
for
sharing
memory
with
concurrency
as
well.
For
example,
there
are
locks,
their
atomic
reference
kind
of
pointers.
There's
all
this
all
these
fancy
things
and
we
as
a
standard
library
decided
to
start
providing
them,
and
we
can
do
this
in
a
way
using
under
ship
and
borrowing
where,
as
the
same
guarantees
as
channels
and
message
passing,
which
is
that
there
are
no
databases.
There
are
very
few
bugs
there
are.
A
This
is
exactly
what
we
need
to
prevent
it
rust.
But
if
you
kind
of
play
that
again
we'll
say
two
threads,
that's
aliasing
at
least
one's
the
right.
That's
mutation
and
unsynchronized.
That's
just
a
fancy
thing
for
something
is
not
a
lot
of
ordering
it's
just
a
Tomic
stuff
to
worry
about
that.
But
that
probably
sounds
pretty
familiar
by
this
point.
This
problem
of
aliasing
mutation
is
also
what
rust
is
trying
to
do
in
a
lot
of
other
aspects.
A
So
if
we
can
just
prevent
these
two
things
from
happening
simultaneously,
we're
missing
one
of
the
key
ingredients
for
data
arrays,
so
we've
actually
already
prevented
data
races.
We
don't
you
really
do
a
whole
lot.
We've
already
solved
all
that
problem,
and
what
this
really
means
is
that,
if
you
don't
have
by
not
having
any
data
bases
in
rust,
you
don't
have
any
accidentally
shared
state.
There's
no
way
to
have
state
cross
a
thread
accidentally.
You
didn't
really
intend
for
that
to
happen.
A
You
could
only
have
to
explicitly
share
state,
and
this
also
means
that
you
can
see
code
like
this
and
C
and
C++
sometimes,
but
you
can't
always
optimize
this.
That
kind
of
look
strictly,
like
oh
yeah
sure
you
can
optimize
that
check
that
check
away,
but
in
c
and
c++
there
might
be
concurrent
access
to
this
variable.
A
You
don't
have
information
about
this
pointer
of
what's
actually
happening,
but
in
rust
we
know
that
these
shared
references
and
these
mutable
references
they're,
never
accidentally
shared
across
threads
there's
no
data
races,
so
we
can
actually
we
have
a
lot
of
optimization
benefits
from
knowing.
There
are
no
data
races
as
well
by
saying
checks
like
this
are
always
true.
You
can
reorder,
writes
you
can
reorder
stores
and
that
that
in
turn
is
very
important
for
various
optimizations
like
vector
writing
and
thanks
stuff,
like
that.
A
So
let's
dive
into
kind
of
how
messages
and
message
passing
and
manifesting
themselves
in
rust
and
if
you're
not
familiar
with
messaging
or
message
passing
it's
pretty
much
just
I
is
the
owner
of
message.
Another
thread
comes
along.
I
can
then
send
message
to
the
messages
to
them,
and
you
can
also
tend
to
send
messages
back
and
resources
back,
so
this
is
mostly
going
to
highlight
how
ownership
is
used
in
Russ
to
kind
of
encapsulate
the
best
practices
of
a
messaging
protocol.
A
So
let's
take
a
look,
an
example:
we
have
this
parent
function
where
the
first
thing
it's
do
is
going
to
create
a
channel.
This
is
just
a
function
in
the
standard
library
and
what
that's
going
to
do
is
it's
going
to
create
a
transmission,
endpoint
and
a
receiving
endpoint,
and
this
is
where
you're
going
to
send
messages
on
the
transmission
in
point
and
then
receive
them
on
the
receiving
end,
and
this
may
seem
kind
of
weird.
A
So,
when
I
created
one
channel,
why
am
I
actually
getting
out
to
things,
and
this
is
actually
pretty
cool
in
the
sense
that
once
we
actually
come
down
and
we
try
and
spawn
this
thread,
the
child
is
going
to
need
access
to
some
some
handle
in
this
channel.
It's
going
to
send
messages
on
something.
So
in
this
case
this.
What
this
closure
here
is
actually
going
to
look
like
it's
something
like
this,
and
the
key
thing
here
is
this
transmission
endpoint
is
captured
by
the
child.
A
This
transmission
endpoint
is
on
there,
but
if
we
still
want
the
parent
to
actually
still
have
access
to
the
messages,
it's
got
a
call
on
something,
so
the
child
has
access
has
now
own
move.
That
or
TX
has
now
moved
into
the
child,
but
we
still
have
to,
but
and
by
having
this
rx
this
other
half
of
a
channel,
we
can
still
have
some
ownership
on
the
parent
itself,
which
can
I
pull
messages
out.
It's
kind
of
just
a
fun
thing
about
rust,
so
this
transmission
in
point
is
going
to
move
over
to
the
child.
A
A
So
one
cool
thing
here
is
that
we
saw
that
there's
a
shallow
copy
going
on
here
or
just
the
data
length
and
capacity,
but
the
actual
contents
of
the
channel
or
the
vector
we're
never
actually
copied.
This
always
stays
at
the
same
place
in
memory,
so
this
is
actually
very
efficient
way
to
send
over,
like
very
large
blocks
like
megabytes
of
data
at
a
time
alright.
So
the
next
thing,
let's
talk
about
is
other
thing
you
might
have
ever
done.
Concurrent
programming,
which
is
just
blocks
mutex
is
this
is
pretty
common
way.
A
You
just
have
a
piece
of
you
have
a
piece
of
data
which
is
protected
by
some
synchronization
primitive,
where
everyone
trying
to
access
it
just
blocks
until
someone
else
isn't
accessing
it,
and
then
you
have
exclusive
access
to
it.
So,
the
way
this
looks
in
rust,
it
looks
a
little
bit
like
this.
We
have
a
function
that
takes
a
mutex,
we're
going
to
lock
it
and
then
we're
going
to
increment
some
data
inside
of
it.
This
looks
pretty
innocuous,
but
that's
actually
a
lot
of
stuff
going
on
here
and
it's
actually
pretty
important
as
well.
A
So
first
we
can
take
a
look
at
this
ampersand
mutex
of
ia-32,
so
this
couple
primary
things
here,
one
this
is
a
shared
borrow,
so,
like
we
saw
earlier,
a
shared
borrow
implies
aliasing.
So
this
is
essentially
saying
this
mutex
might
be
reference
to
other
threads
at
this
point
right
now.
We
don't
actually
have
that
much
knowledge
about
it,
so
we
have
to
assume
there
are
other
threads
that
are
using
this.
A
If
you
block
to
be
txt
and
then
access
it,
so
what
the
mutex
is
doing
is
it
actually
consumed
ownership
of
this
integer
once
the
accurate
went
once
it
was
created,
and
then
from
that
point
on,
because
it
knows
that
it's
the
only
owner
and
the
only
reference
to
that
data,
it
can
then
control
how
it
hands
out
references.
So
you
can
only
access
this
data
through
the
mutex
itself
and
the
way
we
do
that
is.
A
First,
we
create
this
little
data
sentinel,
which
is
kind
of
a
type-
that's
not
actually
a
pointer
in
the
mutex,
but
it's
a
kind
of
placeholder
value
where
the
destructor
is
going
to
release
the
lock
in
a
second.
But
the
key
thing
is
you
can
only
access
the
data
through
the
sentinel
value?
You
can't
access
it
into
the
mutex
at
all,
so
it's
encompassing
this
best
practice
or
the
correct
practice
of
you.
Only
access
the
data
mutex
after
you've
locked
it
once
we've
locked
it.
A
We
have
mutable
access
to
it
because
we
know
there
are
no
other
aliasing.
There's
no
other
threads
aliasing
this,
because
everyone
else
has
the
mutex,
not
the
contents
and
then
also
we're
the
only
alias
of
this.
So
we
have
you
double
access
to
it
and
on
once
we
come
out
because
we
have
this
two
term
is
to
control.
We
have
this
determinism
like
we
haven't
seen
in
C++.
This
data
pointer
falls
out
of
scope
and
then
it
will
release
the
lock.
So
you
never
have
to
actually
unlock
locks
in
rust.
A
You
just
kind
of
what
let
things
fall,
outta
scope
and
it
Chanin
naturally
happens,
and
so
the
next
thing
I
want
to
talk
about.
Is
this
pretty
cool
thing
called
destroying
scoped
access?
This
is
kind
of
a
fancy
way
of
saying
that
you
can
have
a
lot
of
parallelism,
which
is
all
stack
based
where
you
can
kind
of
reference
stack
data,
and
it's
really
convenient
so
I'll
go
through
this
with
an
example
of
the
quicksort
function.
So
those
of
you
who
aren't
very
familiar
with
quicksort
I
always
have
to
remember
this
all
the
time.
A
But
it's
it's
pretty
simple.
All
you
do
is
you
take
a
random
pivot
in
the
vector
and
then
from
this
pivot
element
everything
less
than
the
pivot?
You
move
on
one
side,
everything
big
in
the
pivot.
You
move
on
the
other
side,
and
then
you
rehearse
on
that.
So
this
is
just
saying:
take
a
random
pivot
partition
that
vector
by
moving
greater
than
the
left
bigger
on
the
right.
Well,
then
split
it
into
two
vectors
and
then
we'll
go
and
sort
both
these
sides.
This
is
actually
a
pretty
cool
operation
going
on
here.
A
This
whole
split
at
mute
function.
This
is
saying
we're
taking
a
big
window.
We
are
now
really
quitting
ownership
with
it
and
we're
getting
to
smaller
windows,
so
I
mean
this
is
actually
a
lot
of
stuff
going
on
here
in
terms
of
ownership
and
borrowing.
So
if
we
take
a
look
at
what
split
up
mute
is
in
the
standard
library,
this
function,
signature
is
saying
it's
taking
a
mutable
reference
to
a
slice,
a
point
to
split
it
at
and
then
returning
to
other
mutable
references.
A
So
we
can
see
ownership
at
play
here
in
the
sense
that
it's
consuming
the
first
Moodle
reference,
this
first
mutable
reference
is
not
going
to
be
accessed
again,
so
we
know
that
we
have
the
only
unique
reference,
so
we
can
kind
of
control
access
to
it
at
that
point,
but
borrowings
also
happen
here
where
this
fancy
thing
called
lifetimes,
where
this
the
lifetime
on
this
first
beatable
spar
borrow,
is
now
the
same
as
the
return
to
slices
here.
So
we
know
that
if
we
have
a
slice,
that's
valid
for
a
certain
lifetime
whatever.
A
If
we
kind
of
split
it
up
and
return
subviews
into
it,
they're
also
valid
for
that
same
lifetime.
So
we
can
kind
of
see
both
of
those
at
play
in
this
very
simple
function
of
just
splitting
a
vector
and
kind
of
two
separate
halves.
So
it's
kind
of
more
fun
to
do
this
in
parallel.
So
let's
just
make
a
parallel
quicksort
function,
and
this
looks
pretty
similar
to
the
previous
one.
A
We
kind
of
we're
kind
of
resuming
where
we
left
off,
but
right
after
that,
instead
of
just
doing
it
sequentially
we're
just
going
to
have
this
called
this
made
up
parallel
joint
API
and
all
this
is
really
doing
behind
the
scenes.
Is
it's
going
to
run
these
two
closures,
the
quick
sort
of
the
left
of
the
quick
sort
of
the
right
in
parallel,
and
then
it's
going
to
join
on
the
two
results
and
then
return
once
they
both
returned.
They're
returned
once
they've
both
completed,
so
that
is
kind
of
interesting.
A
A
That's
interesting.
So
this
is
this
is
actually
safe.
This
is
safe
to
do
and
the
reason
this
is
safe
is
because
we
can
actually
be
sure
that
once
these
two
closures
have
returned,
there
are
no
outstanding
references
to
the
stack
data,
so
we
can
safely
say
that
we
can
execute
this
in
parallel,
these
two
disjoint
slices
because
they're
and
we
still
have
mutable
access
to
them.
We
can
pass
it
off
to
102
multiple
threads.
A
This
is
kind
of
this,
isn't
actually
an
existing
API
in
the
standard
library
just
yet
there's
kind
of
some
extra
stuff
bolted
on
to
actually
I
put
this
in
the
ecosystem.
But
this
is
an
example
of
how,
in
rust,
you
can
kind
of
use
these
primitives
and
you
can
use
these
guarantees
of
ownership
and
borrowing
the
immutable
borrows
and
what
they
all
have
access
to,
and
you
can,
at
you
can
implement
a
parallel
quicksort,
essentially
instantaneously,
with
almost
no
effort-
and
one
final
thing
I
want
to
talk
about
in
terms
of
rust.
A
Concurrency
story
is
that
the
channels
are
all
this
is
taking
a
look
at
this:
send
function
for
channels
in
standard
library
and
they're
all
parameterize,
with
this
type
of
message,
that's
actually
flowing
across
the
channel
itself
and
you'll
see
this
interesting
trait
called
send.
This
is
the
send
bound
on
messages,
and
what
this
is
essentially
saying
is
that
only
send
able
types
can
be
sent
across
threads.
That's
kind
of
a
fancy
way
of
saying.
A
Basically
what
these
two
examples
are
here,
which
is
that
arc
is
an
atomic
reference,
counted
pointer,
it's
totally
safe
to
send
across
threads
there.
Any
updates
to
the
reference
count
are
done
atomically,
so
it's
fine
happen
concurrently,
so
it's
we
can.
We
can
send
that
anywhere.
We
like,
but
our
C,
on
the
other
hand,
which
tends
to
reference
counted
pointer,
cannot
be
sent
to
other
threads.
A
You
can't
update
the
reference
count
non-atomic
with
multiple
threads,
that's
a
data
race
which
then
leads
to
undefined
behavior,
and
this
is
actually
pretty
cool
because,
if
you've
ever
used
c++
before
you
probably
seeing
shared
pointer
and
that's
very
similar
to
arc
here
where
the
updates,
the
reference
count,
are
all
atomic.
But
the
problem
is
you
don't
always
send
your
shared
pointers
to
other
threads
and
atomic
updates
are
pretty
slow
compared
to
non
atomic
updates.
A
So
in
rust
it's
giving
you
the
ability
to
control
whether
you
want
to
send
these
to
other
threads
or
whether
you
don't
want
this
on
the
set
of
threads.
So
you
can
you
can
kind
of
trade
off
the
performance
or
whatever?
Is
it
suitable
for
the
application
at
hand?
But
at
the
same
time,
if
you
choose
the
faster
one
which
is
less
feature
'fl,
it
will
also
guarantee
you,
don't
accidentally
send
that
to
another
thread
it
will
guarantee
you,
don't
actually
have
any
data
races
by
leaking
that
to
someone
else
and
so
there's
a
lot.
A
This
is
not
the
full
concurrent
concurrency
story
in
rust.
Concurrency
is
an
area
of
very
active
development
in
rust.
There's
tons
of
things
going
on
the
ecosystem,
we
have
a
lot
of
crates
like
rayon
and
crossbeam,
which
are
exploring
new
new
kind
of
GC
isch
schemes
for
garbage
collection
in
concurrent
situations.
A
Also,
parallelism
like
the
parallel
joint
API
I
was
showing
is
actually
implemented
in
kind
of
in
scope,
threads
in
that
and
rayon
itself,
and
we
have
this
whole
long
list
of
things
that
we
would
like
to
do
in
rust
as
well,
and
these
are
all
enabled
by
the
traits
and
bounds
and
guarantees
that
rust
is
giving
so
far,
and
the
key
thing
to
remember
from
all
this
is
that
everything
you
see
here
is
always
going
to
be
data
race,
free.
This
is
this
guarantee.
A
You
don't
actually
get
from
C
and
C++
there,
many
of
the
languages
where
it's
saying
that
you
can
have
all
this
concurrent
programming.
You
can
do
it
all
very
confidently.
You
don't
really
have
to
worry
about
all
these
extra
weird
things
going
on.
You
can
kind
of
use
ownership
in
rust
to
leverage
all
that
fact
to
prevent
all
these
bugs
at
compile
time.
A
So
all
of
this
seems
kind
of
nice.
But
how
are
we
actually
implementing
any
of
this
channels
themselves
are
all
in
the
standard
library
the
mutexes
are
in
the
center
library.
All
of
rust
is
actually
written
in
rust,
so
some
of
these
were
kind
of
bending
some
of
the
rules
we
saw
earlier
about
ownership
and
borrowing
and
what
rust
has
to
solve.
A
That
is
this
unsafe
concept,
this
concept
of
unsafe
code
and
in
rust
that
ends
up
coming
out
is
safe,
abstractions,
and
you
can
do
this
by
so
you
can
enter
the
unsafe
code
of
rust
by
having
an
unsafe
block
where
you're
basically
telling
the
compiler
trust
me
I
got
this
so
I'm
going
to
take
care
of
any
any
invariants
you
want.
Any
variants
you
have
I
will
make
sure
that
they
are
true
at
the
end,
because
you
made
sure
they
were
true
at
the
beginning,
and
this
allows
you
to
kind
of
bend.
A
The
mutation
and
aliasing
rules
so
bring
several
the
split
at
mood
function.
We
can't
implement
that,
given
one
mutable
slice,
we
can't
really
split
that
up
into
two
like
we,
as
the
implementers
know
that
the
two
we're
going
to
return
are
disjoint,
so
it
is
safe,
but
the
compiler
won't
understand
that
that
slice
is
actually
the
those
two
sub
slices
are
destroying.
A
So
we
have
to
rely
on
unsafe
code
to
actually
have
about
this,
and
then
also
whenever
you
touch
C
called
FF
I
call
it
two
other
libraries
we
assume
those
are
entirely
unsafe
because
they
could
essentially
change
the
world
in
any
way,
shape
or
form.
So
you
have
to
use
unsafe
code
when
interfacing
with
C,
but
the
key
thing
in
rust
is
that
you
don't
ever
actually
write
this
that
often
when
you're
writing
your
big
application,
you're
pretty
rarely
relying
on
unsafe
code
and
the
reason
for
that
is.
We
have
this
safe
boundary
to
rust.
A
We
say
that
we
have
our
safe
function,
which
is
might
do
some
input,
validation.
It
might
kind
of
do
some
verification
and
then
it
will
actually
go
and
run
this
unsafe
code
which
isn't
allowed
elsewhere
and
so
an
example
of
these
safe
abstractions.
Is
this
mutex
he
was
looking
at
I
was
showing
earlier.
This
mutex
was
a
shared
reference
which
I
said
at
the
beginning
was
essentially
immutable.
You
can't
actually
meet
8
through
it,
but
then
we
were
locking
in
actually
mutating
through
it.
A
So
that's
kind
of
an
example
of
bending
these
aliasing
rules
as
well
and
kind
of
bending.
This
mutation,
where
it's
still
safe,
like
mutexes,
are
a
safe
paradigm
in
rust,
but
you
can
kind
of
use
unsafe
internally
to
implement
that
and
then
the
X,
the
API
you
export,
is
all
totally
safe.
So
there's
no
actually
unsafe
way
to
use
the
mutex
itself,
all
right
so
to
kind
of
wrap
up
here.
A
If
you
take
a
look
at
this,
is
one
of
my
favorite
quotes,
as
the
rust
community
seems
to
be
populated
by
entirely
human
beings,
and
this
is
this
is
actually
pretty
telling
and
it
boils
down
to
if
you
take
a
look
at
before
1.0,
we
had
over
a
thousand
contributors,
and
it's
this
incredibly
welcoming
and
supportive
culture
where,
if
you
come
into
rust,
to
kind
of
come
in
the
rest
channels,
questions
will
be
answered
almost
instantaneously.
Any
sort
of
changes
or
PRS
rusts
are
very
welcome.
Our
tons
of
review
happens
on
them.
A
The
community
is
very
supportive
and
all
this
interaction-
it's
just
it
surprises
some
people
with
that.
Oh
my
god,
people
are
actually
here.
People
cared,
people
are
actually
looking
at
this
kind
of
stuff,
but
at
the
same
time,
there's
always
this
notion
of
getting
a
little
bit
down-to-earth,
making
sure
everything
is
practical
to
make
sure
everything
is
usable.
I
can
actually
use
this
on
my
every
day,
job
or
in
terms
of
ergonomics
in
terms
of
actually
shipping.
A
A
All
the
major
products
are
of
rust
today,
and
this
is
not
only
followed
by
the
community,
but
also
the
core
team
itself,
and
the
core
team
has
tons
of
back-and-forth
on
our
FCS
as
well,
and
everyone
and
tons
of
iteration
over
what's
actually
happening,
but
through
all
this
there's,
always
a
clear
leadership
of
rust
itself.
The
core
team
has
a
very
large
mix
of
backgrounds
on
on
it
to
kind
of
ensure
that
the
language
has
a
very
healthy
upbringing
in
terms
of
diversity
of,
what's
actually
happening
and
we're
essentially
keepers
of
the
vision.
A
We
essentially
make
sure
that
rust
is
always
going
towards
a
kind
of
unified
vision,
and
we
help
steer
the
community
in
rfcs
an
entire
process
towards
this
vision,
to
ensure
we're
all
working
towards
the
same
shared
goal
and
some
examples
of
RFC's
that
we've
seen
are.
This
is
an
RFC
for
a
new
language
feature
which
has
tons
of
comments,
though
tons
of
iteration.
A
That
happened
over
it
sums
of
changes
that
happened
over
time,
but
it
was,
it
always
came
out
for
the
best
like
this
was
something
I
think
I
remember
talking
about
this
in
designing
it
a
long
time
ago,
and
then,
by
the
time
we
actually
got
to
the
end
of
the
RFC
process,
it
was
almost
totally
indistinguishable
for
we
had
started,
which
were
the
better,
because
we
get
all
these.
We
get
all
these
points
of
view
and
all
these
opinions
we
just
couldn't
even
fathom
to
think
about
beforehand.
A
Until
we
actually
came
to
the
community
and
said
hey
everyone
like
what
do
y'all
think
of
this,
and
it
not
only
ranges
in
the
RFC's
in
terms
of
language
features
as
well,
but
also
pretty
complicated
internals
of
the
compiler.
This
is
something
that
I.
Don't
actually
myself
really
understand
that
much,
and
this
is
kind
of
a
subsection
of
the
RFC,
which
I
also
really
don't
understand
that
much
there's
a
lot
of
crazy
stuff
going
on
here,
but
we
have
an
entire
section
of
the
community
which
is
also
working
on
this.
A
If
you
see
this
also
has
tons
of
comments,
and
our
community
is
certainly
very
in
terms
of
interests
and
you'll
see
lots
of
different
points
of
view
and
aspects
looking
into
this
so
to
wrap
up
what
rust
is
essentially
doing
is
kind
of
giving
you
these
really
nice
guarantees
which
are
very
difficult
to
find
in
other
languages.
So
Russ
is
giving
you
memory
safety
without
garbage
collection.
It's
giving
you
this
control
without
sacrificing
on
safety.
At
the
same
time,
it's
giving
you
concurrency
without
data
races.
A
So
all
these
things
you
were
afraid
to
do
it
before
or
retrofit
on
existing
code
bases.
You
can
do
it
anytime
in
rust,
because
you
can
be
you
can
safely
say
if
it
doesn't
compile
it's
not
going
to
work
and
if
it
compiles
it's
probably
going
to
work.
It
gives
you
abstraction
without
overhead,
which
is
the
same
level
of
control
that
C
and
C++
gives
you.
It
allows
you
to
go
straight
down
the
machine.
You
know
exactly
what's
running
you,
you
can
actually
look
at
rusts
code
as
well
and
reason
about.
A
Oh,
this
is
probably
the
assembly
instructions
that
are
running.
This
is
how
I'm
going
to
vectorize
this
loop.
All
these
crazy
optimizations.
You
do
and
see
them
C++.
You
can
still
do
in
rust
and
then.
Finally,
it's
also
giving
you
stability
without
stagnation.
We
had
this
massive
community,
which
has
been
pushing
rough
since
1.0,
and
if
you
take
a
look
at
the
difference
between
rust,
1.0
and
1.9
that
was
released
publix
ago.
It's
massive
we
had
tons
of
new
features
in
the
standard
new
api
is
in
the
standard
library.
A
We
have
a
huge
ecosystem
growing
in
terms
of
new
crates
being
developed,
two
new
features
in
cargo
or
package
manager.
It's
very
much
making
very
steady
progress
ever
since
1.0
because
of
this
massive
community.
Push
behind
it
and
the
TLDR
of
all
this
essentially
and
kind
of
rust
in
general
is
that
you
can
hack
without
fear.
You
can
just
work
in
rust
and
just
stop
worrying
about
all
these
random
site
faults
and
debugging
and
weird
sessions
in
rust
or
in
very
subtle
language
and
languages
that
you
have
that's
all
I
have
for
date.
A
Right,
so
that's
actually
one
thing
that
I
also
like
to
talk
about
as
well.
Let
me
see
what
that's
like
was
yes,
this
one.
So
if
I
had
a
mutable
reference,
remember
a
mutable
reference.
If
you
have
it
is
the
only
way
to
access
that
data.
So
if
you
have
a
mutable
reference
to
a
mutex
like
ampersand
mutex,
no
one
else
can
have
an
access
that
mutex.
B
A
Were
the
only
one
with
a
pointer
to
that
mutex,
in
which
case
locking
actually
doesn't
make
sense?
Because
you
already
have
you
double
access,
so
you
can
actually
go
straight
in
there
and
grab
the
data.
So
the
shared
way
is
saying
the
shared
reference
is
implying
is
saying
that,
like
this
is
safe
to
share
among
many
threads,
you
can
have
references
among
many
threads
and
because
you
don't
actually
know
if
there
are
at
like
at
runtime,
you
have
to
go
in
a
part
of
the
lock
that
make
sense.
C
A
Right
we've
actually
had
in
long
ago
and
rust
we
actually
attempted
to
prevent
deadlocks,
turns
out
it's
kind
of
hard,
so
preventing
deadlocks
isn't
actually
requirement
for
memory
safety,
it's
more
of
like
if
your
program
never
terminates.
Well,
it's
still
never
going
to
cycle.
So
we
actually,
we
do
nothing
at
term.
In
terms
of
that,
you
you
can
met,
you
can
write
concurrent
programs
that
are
certainly
wrong,
but
though
they'll
never
have
data
race
is
another
side
fall,
it's
just
they
might
deadlock.
They
might
have
like
weird
results.
It's
just
weird
to
find
results.
D
A
A
You
just
you
forget
about
the
slices,
and
then
you
have
the
original
slice
back
as
well,
and
this
happens
because
all
you're
doing
is
this
original
slice
when
you
borrow
it
you're,
actually
taking
a
lifetime
loan
out
on
it
so
like
during
that
lifetime
of
which
you
borrowed
it,
you
can
only
access
those
two
slices,
not
the
original
one.
Well,
once
that
lifetime
expires,
you
can
come
back
the
original
slice
itself.
A
A
A
As
a
very
good
question,
the
answer
is
not
so
good.
So
if
you
take
a
look
at
the
analysis
and
compile
types
and
rust
is
something
that
we
are
very
much
aware
of
and
very
much
we're
working
to
improve,
and
the
biggest
thing
here
is
actually
almost
90%
of
our
time
in
terms
of
compile.
Time
is
translating
the
LLVM
LLVM
is
our
back-end,
which
is
just
the
same
back
in
for
like
c++
and
clang
and
then
also
in
optimizations.
A
So
that's
kind
of
the
major
slowdown
is
actually
just
generating
all
this
code
and
optimizing
all
this
code
and
so
we're
looking
at
a
couple
things
we're
actually
we're
doing
a
massive
compiler
refactoring
now
to
just
plum
through
a
new
ir
ourselves,
where
it's
going
to
make
translation
times
much
much
faster
and
then
also
we
can
enable
optimizations
on
our
own
in
our
own
compiler.
Currently
we
do
new
optimizations,
but
eventually,
once
we
do
that
we
might
be
generating
less
code
and
then
the
other
major
feature
is
we're.
A
Adding
incremental
compilation
soon,
which
is
that
currently,
the
unit
of
compilation
and
rust
is
much
much
larger
than
in
C++.
So
you
feel
the
pain
of
this
compile
time
very
iteratively
over
time.
But
what's
going
to
happen,
is
this
once
we
have
this
increment
compilation,
we
do
the
unit
of
agreement.
Ality
is
going
to
be
much
much
smaller,
so
the
actual
work
you
have
to
redo
whenever
you
kind
of
modify
something
and
recompile
to
see
if
it
works,
is
much
much
smaller.
A
So
a
lot
of
improvements
are
coming
here
soon,
but
in
general
the
compile
times
tend
to
be
better
than
C++
in
terms
of
one
absolute
compile
any
benchmark.
I've
ever
seen
from
a
similar
C++
project
to
a
similar
Russ
project
compiles
in
essentially
the
same
amount
of
time.
We're
rust
is
almost
always
a
little
bit
faster
if
not
way
faster.
It's
just
this.
This
iterative
process
of
kind
of
modifying
a
little
bit
in
C++.
You
have
to
recompile
very
little,
we're
in
rough
state
free,
compile
a
lot
but
that'll
be
fixed.
A
E
A
So
you
would
sacrifice
too
much
performance
to
have
an
overflow
checks
in
release
mode,
so
by
default
they're
turned
off.
You
can
turn
them
on,
though,
and
once
you
have
them
turned
on
in
release
mode.
They
are
defined
as
two
DES
two's
complement,
so
they're
they're,
not
undefined
behavior.
It's
totally
fine
to
happen.
They
are
defined
as
wrapping
around
and
debug
mode
you'll
catch
it
and
in
a
release
mode.
You
can
turn
it
on,
but
by
defaults
turned
off.
C
A
They're,
actually
it's
there's
a
surprising
number
of
graphics
libraries
in
rust
today,
if
there's
been
a
lot
of
push
towards
not
using
like
OpenGL
and
a
kind
of
all
that
crazy
stuff
I'm,
not
the
best
person
to
talk
about
this
I
know
there's
many
many
others,
but
there
are
many
projects
that
are
like
games
written
in
rust,
OpenGL
bindings,
written
in
rust,
new,
like
GL
FW
written
in
rust
itself.
I,
don't
know
a
lot
about
graphics.
Was
that
answering
your
question?
Oh.
A
In
that
sense,
running
rust
directly
on
the
on
the
GPU.
Oh
sorry,
so
that
has
been
done
in
the
past.
There's
not
currently
a
majorly
stable
way
to
do
that.
We're
in
terms
in
terms
of
a
code
generator
we're
limited
by
mostly
what
LVM
does
so
Ella
VM
does
have
the
ability
to
do
that
and
I've
seen
people
write
like
little
small
kernels
that
actually
run
on
the
graphics
card
itself,
but
that
was
years
ago
before
I
even
hit
1.0
when
there's
nothing
stable
in
the
compiler.
Currently,
yes,.
A
This
is
actually
something
I
forgot
to
say,
but
this
bracket
here
is
actually
not
a
vector,
it's
kind
of
terrible
name,
though
think
about
it.
This
is
actually
a
slice,
so
a
slice
in
rust
is
just
a
window
into
array,
so
there's
actually
no
push
operation
on
this.
You
can't
actually
push
because
this
is
not
even
a
method.
We
have
this
like
a
mutable
reference
to
a
vector,
you
can
push
on
a
mutable
reference
to
a
slice.
A
B
A
This
is
the
syntax
for
closures,
so
if
you
have
like
bracket
argh
a
bracket,
that's
like
a
closure
that
takes
one
argument,
and
then
this
lip
expression
is
the
thing
afterwards
is
just
the
body
of
the
closure.
It
was
also
this
better
example
on
the
channel
slide
this
one.
So
you
can
see
the
this.
These
double
bars
are
saying:
there
are
new
arguments,
this
closure
and
then
the
curly
braces
are
signing
the
body.
This
closure
is
the
stuff
inside
there.
The
move
is
just
a
don't
worry
about
that.
A
It
kind
of
depends
what
you're
actually
sharing.
So,
if
you,
if
you
pass
around
this
vector
and
like
you're,
just
passing
around
this
ampersand
back
about
32,
you
actually
just
passing
around
the
pointer
value
itself,
so
you're
not
creating
more
and
more
references,
but
he
passed
around
like
ampersand
ampersand,
becca-pie
32.
Then
you
are
creating
a
reference
chain.
It's
one!
You
have
to
like
explicitly
up
and
opt
into,
and
you
probably
won't
be
creating
like
a
presenter
sign
types
and
every
stage
it
probably's
one
happen
that
often.
D
B
C
A
There's
actually
some
small
projects,
I
think-
and
maybe
a
big
grant
doing
this
actually.
But
it's
trying
to
look
at
specifically
the
unsafe
subset
of
rust
and
trying
to
prove
various
things
about
it.
So
you
could
hand
this
analysis
tool.
Bunch
of
this
and
say
like
these
are
like
this
piece
of
unsafe
code
is
actually
just
safe
in
its
entirety
that
make
sense
it's
we.
We
can
certainly
talk
a
little
more
about
the.
If
you
want
to.
A
That's
also
a
very
good
question.
Unfortunately,
I
will
say:
Idris
was
way
better.
It
was
really
good.
Like
writing
your
program,
for
you
is
not
something's
gonna
happen
intervals,
unfortunately
yeah,
but
the
IDE
support
is
kind
of
in
progress
and
coming
along
so
like
if
you're
kind
of
working
in
vim
or
Emacs
kind
of
the
bare-bones
works,
I
think
IntelliJ
is
actually
coming
pretty
good
in
terms
of
auto
completion.
We've
had
this
project
called
racer
in
the
past,
which
it
works.
A
Well,
it's
not
perfect,
but
one
of
the
major
motivational
factors
of
the
incremental
compilation,
story
and
kind
of
this
major
refactor
of
the
compiler
we're
doing
right
now
is
that,
if
we're
going
to
enable
the
sort
of
IDE
support,
so
we
have
a
lot
of
designs
for
the
concept.
This
whole
rust
language
server,
which
is
kind
of
a
long-running
daemon
which
you
feed
code.
You
can
just
query
it
from
things
like
what
are
the
other
completions
here.
Your
word
of
the
methods
here.
What
are
the
types
here
kind
of
happens
over
time?
A
It's
not
implemented
yet
so
we'll
kind
of
see
this
develop
over
time
once
the
incremental
starts
moving
a
little
farther,
but
it's
something
that
we
actually
so
we
have
a
survey
at
the
beginning
this
year
and
the
number
one
thing
that
was
requested
was
more
IDE
support.
So
we're
going
to
see
a
lot
more
develops
on
that
as
the
year
goes
on.
A
Right
so
I
think
from
what
I
currently
know,
all
full-time
developers
of
rust
are
currently
paid
by
Mozilla
all
within
the
Muslim
research
organization,
the
core
team
itself.
We
don't
have
much
financing
for
rust
in
terms
of
like,
like
managing
what
I
found
through
a
foundation
or
anything.
Currently
it
might
happen
eventually,
but
also
the
core
team
is
not
exclusively
Mozilla
right
now
we
have
a
couple
members,
for
example,
from
tilde
or
some
independent
contractors,
and
actually
a
guy
working
in
Apple.
Now,
although
he
just
started
as
a
new
employee,
yes.
D
A
I
I'm
not
super
familiar
with
those
kinds
of
architectures,
but
I
can
I
did
most
of
the
time
whatever
you
would
do
in
C++,
C
and
C++
is
essentially
which
do
the
same
thing
in
rust.
So
in
terms
of
like
bare
metal
abstractions,
you
can
actually,
there
are
two
somewhat
Center
libraries
and
rust,
there's
the
manger
standard
library
and
then
there's
the
component
inside
of
it
called
Lib
core,
which
is
actually
just
a
subset
of
the
standard
library
itself,
and
this
is
a
subset
which
doesn't
understand
how
to
allocate
doesn't
understand
how
to
spawn
threads.
A
That's
kind
of
like
doing
the
most
predictable
thing
you
would
expect
from
C,
so
you
can
drop
down
to
that
to
not
use
any
extra
allocation
or
like
not
use
any
extra
fluff.
Otherwise,
it's
just
like
when
you
allocate
like
currently
by
we
default
to
J
malloc,
but
you
can
swap
that
out
to
something
else,
but
you
would
have
control
kind
of
as
long
as
Elvin
can
express
it
as
long
as
you
can
express
it,
the
source,
language
and
C
and
C++,
it
would
essentially
be
the
same
in
rust.