►
Description
In 2010, Mozilla announced it was working on a new systems language, aiming to match the performance and C-interoperability profile of C++ in a provably safe language with concurrency, immutability, isolation and expressiveness properties closer to languages like Erlang, Haskell or Scala.
While Rust presents a good variety of familiar, expressive tools from other mainstream languages, it also borrows from research languages two lesser-known key technologies: "owning pointers" and "borrowed pointers". This talk will briefly describe the Rust language in general terms, then focus in on these two key technologies, how they shape Rust's memory model, performance and safety guarantees, and why you might consider using Rust in your next project.
Nicholas Matsakis
Nicholas Matsakis is a senior researcher at Mozilla research.
He focuses on safe support for parallelism in programming
languages. He is currently working on the Rust programming language as
well as Parallel JavaScript.
http://linux.conf.au/schedule/30170/view_talk?day=friday
A
Oh
great
thanks
very
much
hi
so
yeah,
my
name
is
Nicholas
Metis
I
work
at
Mozilla,
research
and
I
want
to
talk
to
you
guys
today
about
the
rust
programming
language
which
we're
developing
well
I
shouldn't,
say
we're
developing
it
because
Mozilla
research
is
kind
of
spearheading
it.
But
the
truth
is
that
without
the
community
that
we've
got
involved,
we
wouldn't
be
able
to
do
nearly
as
much
so
I'm
really
grateful
to
everyone.
Don't
know
if
there
any
volunteers
here
but
to
all
the
volunteers
out
there.
A
A
Second,
if
you
have
any
questions
as
I
go,
please
feel
free
to
ask
them
while
I'm
talking
and
not
wait
till
the
end,
because
a
lot
of
the
ideas
I'm
talking
about
kind
of
build
on
one
another.
So
if
you
get
confused
in
the
beginning,
it
could
be
easier
or
the
rest
of
the
talk
might
make
more
sense
if
we
clarify
it
first.
A
The
first
thing
I
want
to
answer
is
the
question.
I
get
asked
you
know
first
when
I
say
that
I'm
from
Mozilla
research
and
we're
working
on
a
programming,
language,
most
people
say
kind
of
Mozilla.
What
you
know
I
thought
you
guys
made
Firefox.
Why
are
you
working
on
a
programming
language?
And
the
answer
is
that
you
know
first
of
all,
yes,
Mozilla
has
a
research
arm
and
our
goal
is
to
kind
of
look
at
what
we
can
do
to
make
the
web
model
more
successful
and
make
it
apply
to
more
things.
A
So
things
like
as
MJS
Firefox
OS
that
were
mentioned
in
the
introduction.
Those
came
out
of
Mozilla
research
actually
well
to
some
extent
or
our
collaboration
with
us
and
another
thing
that
we're
looking
at
is:
what
can
we
do
just
to
reaaargh
attack
the
browser
itself?
It's
not
just
HTML
and
CSS
and
expanding
the
scope
of
those,
but
the
browser
itself.
The
basic
design
hasn't
really
changed
a
lot
since
netscape
days
and
computers
have
changed
a
little
bit.
You
know
we
have
multi-core.
A
A
So
when
you
have
8
million
lines
of
code,
you
can
bet
that
somewhere
in
there,
you
know,
is
more
than
a
couple:
seg
faults
and
security,
vulnerabilities
and
so
forth,
and
so
that's
kind
of
a
good
reason.
Why
not
to
use
C++,
but
maybe
there's
another
language
out
there?
Why
do
we
have
to
make
our
own
right?
The
problem
is
that
most
languages
that
are
out
there
fall
along
a
line
like
this.
They
kind
of
trade-off,
control
and
safety.
A
So
for
C++
you
get
a
lot
of
control,
but
not
a
lot
of
safety,
and
then
you
have
on
the
far
extreme,
on
the
other
side,
something
like
Haskell,
which
gives
you
a
whole
lot
of
safety,
but
very
little
actual
control
of
what
the
machine
is
doing.
You
have
to
know
a
lot
of
if
the
compiler
will
do
a
lot
of
fancy
tricks
and
the
runtime
does
a
lot
of
fancy
tricks
to
make
it
run
fast.
A
But
if
you
as
the
programmer
want
to
get
control,
it's
a
much
more
complicated
process
and
in
between
I
think
most
other
languages
kind
of
fall
somewhere
along
this
line.
So
there's
something
like
Java,
where
you
have
a
lot
more
control
than
Haskell,
but
you
still
have
this
runtime
in
the
background,
and
so
on.
The
idea
of
rust
is
to
say:
can
we
just
step
off
this
line
altogether?
Can
we
have
the
same
control
or
similar
as
we
get
in
C++,
but
with
the
same
kind
of
safety
guarantees
that
Haskell
gives
us?
A
Here's
a
little
fragment
of
C++
and
the
first
thing
it
does
is:
it
creates
a
hash
map
and
one
of
the
nice
features
of
C++
is
you
can
put
this
hash
map
kind
of
on
the
stack
and
we'll
see
what
that
means
in
more
detail
in
a
second,
but
basically
it
means
that
when
this
function
returns
or
this
block
exits,
we
know
deterministically.
The
map
is
going
to
get
freed
right,
then
alright
and
that's
good
for
keeping
memory
usage
down
and
so
forth.
A
A
It
gives
me
a
pointer
right
back
in
the
middle,
and
that
means,
if
my,
if
the
value
that
I'm
putting
in
this
map
is
big,
that's
that's
a
better
way
to
do
it
and
I
don't
have
to
have
layers
of
indirection
and
so
on,
but
I
can
make
some
really
trivial
mistakes.
So
here
I'm
going
to
take
that
pointer
right
into
the
middle
of
the
map
and
I'm
going
to
return
it
to
my
caller,
and
the
problem
is
I,
just
told
you
that
the
map
is
going
to
get
freed
as
soon
as
my
function
returns.
A
So
now,
I
have
a
pointer
into
freed
memory
and
I'm
returning
it
to
the
caller
and
that's
a
recipe
for
disaster
right.
So
let
me
sort
of
I'm
going
to
do
this
sort
of
stepping
through
the
execution
a
couple
times
in
the
talk.
So
let
me
do
it
here
for
the
c++
to
reiterate
what
I
just
said.
So
what
that
program
does
the
first
thing
it
does
is
it
creates
a
map
and
in
fact
the
data
is
not
all
on
the
stack.
A
A
This
is
a
single
pointer
and
it
goes
directly
into
the
heap
there
and
then
finally,
we
return
that
pointer,
so
what's
happening
now,
is
that
pointer
got
copied
from
the
topmost
stack
frame
into
the
caller
and
then
we're
going
to
free
the
the
topmost
stack
frame
and
all
of
the
data
that
it
owns
and
when
I
do
that
now
you
see
this
pointer
here
is
just
pointing
out
into
that
greyed
out.
Hopefully
that
works.
A
You
have
a
problem
that
can
crop
up
anywhere,
so
it's
kind
of
like
this
house
here
from
my
view
anyway,
each
of
those
bricks
is
a
piece
of
memory,
and
if
you
just
have
one
that's
taken
from
the
wrong
place,
the
whole
thing
can
come
crumbling
down
right.
So
what
do
people
normally
do
in
most
languages?
They
will
use
a
garbage
collector
to
solve
this
problem,
and
that
is
a
great
solution,
a
lot
of
the
time
yeah.
But
the
problem
is
in
some
particular
spaces.
A
garbage
collector
isn't
so
good.
A
So
what
a
garbage
collector
does
is,
instead
of
freeing
the
memory
manually,
it'll,
basically
just
periodically,
search
through
all
the
pointers,
you
have
and
find
all
the
memory
that
you
don't
have
a
pointer
to
and
it
will
free.
It
then
right.
The
problem
is
that
this
introduces
overhead,
it
introduces
kind
of
unpredictable
pauses
and
there
are
various
ways
to
to
address
this
by
making
interruptible
garbage
collectors
and
so
on.
But
nonetheless
you
have
this
runtime
in
the
background,
and
that
makes
it
really
hard
to
integrate
with
a
lot
of
other
languages.
A
So
one
example
is
just
taking
a
library
that
requires
a
runtime
or
a
garbage
collector
and
using
it
with
some.
Some
random
C
program
is
a
little
bit
difficult,
but
it's
also
hard
to
integrate
with
other
virtual
machines
and
especially
with
other
garbage
collectors
like,
for
example,
the
one
in
JavaScript
right.
So
since
we
want
to
write
a
browser,
we
have
to
worry
about
that
kind
of
thing,
and
this
is
just
not
really
the
best
way
to
go
about
it.
So
what
we've
done
in
rust
is
take
a
different
approach.
A
Essentially,
what
we
said
is:
let's
take
that
same
C++
and
all
those
safety
rules
that
you
were
supposed
to
be
enforcing,
but
you
weren't
necessarily
doing
it
and
let's
have
the
compiler,
enforce
those
safety
rules
for
you
and
the
compiler
is
going
to
be
pretty
rigorous
about
it.
You
know
so
basically
it
amounts
to
coming
up
with
a
set
of
conventions
that
guarantee
that
you're,
following
all
the
rules
you're
supposed
to
follow
and
enforcing
them
in
a
religious
sort
of
rigorous,
strict
way.
A
The
advantage
of
this
is,
you
don't
need
a
runtime
because
you're
not
making
them
states
that
the
runtime
was
supposed
to
catch
for
you,
so
to
be
fair,
I
called
this.
The
rust
solution,
but
really
the
rust
solution
is
taken
by
bits
and
pieces
from
lots
of
other
languages
and
a
lot
of
academic
research
and
so
forth.
So
I
think
the
made
the
biggest
influences
are
probably
C
in
C++,
of
course,
Haskell
and
Erlang
and
cyclone,
which
is
an
academic
language,
but
you
know,
I
think
gives
you
you
know
a
lot
of
programming.
A
You
know
in
a
way
that
basically
is
as
flexible
as
C,
so
that
means
we
could
use
rust,
for
example,
to
implement
a
kernel
or
to
implement
a
library
that
plugs
into
some
other
program
and
embedded
projects.
Things
like
that
now,
there's
one
caveat:
I
have
to
point
out:
I
say
that
we
prevent
all
the
these
horrible
bugs
and
we
you
know,
do
except
if
you
link
to
C
code.
Well,
we
can't
help
you.
A
A
We've
tried
to
take
a
lot
of
the
nice
niceties
that
you
may
have
found
on
other
languages
like
pattern
matching
and
so
forth,
and
we
tried
to
offer
those
two
to
make
just
to
make
everyday
programming
a
little
more
pleasant
and
one
of
the
things
we
do
offer,
or
at
least
plan
to
it's
still
being
hacked
on
actively
as
we
speak,
is
an
optional
garbage
collector,
because
I
spent
some
time,
trashing
garbage
collection.
But
the
truth
is
it's
often
very
useful.
It's
only
in
certain
contexts
where
it's
it's
really
not
what
you
want.
A
A
Basically
you
have
this
control
and
safety
dichotomy.
I
talked
about
right,
so
the
most
the
way
to
get
the
most
control
out
of
your
memory
management
is
probably
something
like
malloc
and
free.
It's
pretty
flexible.
You
know
exactly
when
memory
is
getting
freed.
It's
when
you
called
free,
but
it's
pretty
risky.
A
So
what
Russ
does
is
to
say,
let's
keep
this
kind
of
malloc
free
model,
but
let's
put
let's
put
a
build
on
top
of
it:
a
set
of
conventions
that
make
sure
you're
doing
it
in
a
reasonable
way,
and
we
call
those
ownership
and
borrowing
so
I.
Think
ownership
is
pretty
analogous
to
real
life
in
some
ways
at
least
a
kind
of
weird
version
of
your
life.
A
A
So
if
you
think
about
ownership
and
a
book,
if
I
have
a
book,
I
have
it
in
my
bookshelf,
I
own
it
and
other
people
don't
right.
So,
basically,
if
they
want
to
read
that
book,
they
have
to
come
to
me
first,
because
it's
in
my
bookshelf,
they
can't
just
have
their
own
copy
floating
around
or
if
they
do
it's
a
separate
book.
Well,
it
works
the
same
way
with
a
data
structure
in
rust.
A
So
if
I
have
like
a
hash
map
or
something
and
I'm
a
stack
frame,
let's
say
I
own-
that
hash
map
I
know
that
there
are
no
other
aliases
to
it.
Nobody
else
has
that
same
map
right
and
that
has
some
nice
implications.
For
example,
I
know
I
can
just
free
it
anytime
I
want
to
because
nobody
else
has
a
pointer
to
it.
So
they
won't
have
a
problem
if
it
goes
away
right
and
in
fact
I
don't
even
have
to
do
it
explicitly
I'm
the
only
one
that
has
that
map.
A
So
when
I'm
finished
with
it,
when
I
quit
or
return,
we
can
just
free
it
right.
I've
always
wanted
to
use
that
fire
transition
and
I
never
had
a
justification,
but
so
so
that's
basically
how
it
works
with
data
structures
and
memory
management,
but
the
other
thing
I
can
do
if
I
own,
something
is
I,
can
give
it
away
and
I
can
transfer
it.
A
So
I
might
give
my
book
to
you
and
in
that
case,
once
I've
done
that
it's
yours
now,
I
don't
have
it
anymore
and
because
it's
yours,
if
you
are
finished
with
it,
you
can
free
it
right,
you're,
the
owner
now.
So
let's
look
at
some
code
and
see
what
I
mean.
This
is
a
little
bit
of
rust
code
and
this
actually
would
not
compile
and
we'll
see
why,
later
or
in
a
minute,
but
let's
kind
of
step
through
it.
A
The
first
thing
it
does
is:
it
creates
a
hash
map
and
for
those
of
you
who
know
C++
you'll
see
the
word
new
there
and
you'll
think
memory
allocation.
It's
not
a
keyword
in
rust,
it's
just
the
name
of
a
function
that
by
convention
returns
a
new
hash
map.
But
basically
what
we're
going
to
wind
up
with
is
exactly
that
same
setup.
A
A
It's
been
transferred
to
the
caller
and
now
because
the
function
take
owns
it
function,
take
can
go
and
do
some
stuff
to
the
map
and
when
take
returns,
the
map's
going
to
get
freed
because
take
is
the
owner
and
so
will
be
will
be
returning
now
to
the
call
to
the
original
function
that
the
only
difference
is.
We
don't
have
the
map
anymore,
and
this
is
where
the
error
comes
in.
So
if
we
tried
to
use
it
again,
we
would
get
a
compilation
error
right
here.
A
A
So
that's
all
good,
but
sometimes
you
know
I
have
a
book
and
I
read
it
and
it
was
nice
I'm
not
really
done
with
it,
but
I
might
think
my
friend
might
like
it
so
I
could
give
it
to
them
on
the
agreement
that,
sometime
later,
you
know
they're
going
to
give
it
back
to
me.
This
is
called
borrowing
right
kind
of
a
convoluted
explanation,
but
it
works
the
same
way
with
data
structures.
A
If
you
think
about
it,
like,
maybe
you
have
a
hash
map,
and
you
didn't
mean
for
that
function
that
you
gave
it
to
you,
have
some
helper
function,
you
didn't
mean
for
them
to
free
it.
They
were
just
supposed
to
read
it
for
a
little
while
insert
some
entries
take
some
entries
out
and
then
you
want
it
back
at
the
end.
So
we
call
that
the
same
thing
you
don't
have
to
give
data
structures
to
the
caller
to
the
functions
you
call
you
can
lend
them
out
and
the
main
point
that's
most
important.
A
What
separates
rust
from
other
things
is
that
these
temporary
references
that
you
use
to
give
temporary
access.
They
are
a
different
type
from
other
kinds
of
pointers
and
they
have
a
lifetime
which
is
basically
the
span
of
time
in
which
they
are
valid
right.
So
then
I
lend
it
out
to
the
helper
function.
If
the
helper
function
is
going
to
use
it
in
return,
the
lifetime
might
be
the
time
it
takes
for
that
helper
function
to
execute
and,
most
importantly,
the
compiler.
A
Well,
while
me
step
back
if
let's
go
back
to
real
life
for
a
second,
if
I've
lent
my
book
to
a
friend,
I
haven't
given
it
away,
but
there's
still
a
little
bit
different
from
not
lending
it
right.
It's
not
in
my
bookshelf,
so
there's
some
things:
I
can't
do
like
I
can't
throw
it
away.
I
can't
give
it
to
somebody
else,
not
until
I
get
it
back.
A
Well,
it's
the
same
way
with
these
data
structures
when
I
borrow
it
out
if
I
have
a
helper
function,
while
that
helper
function
is
executing,
there
are
some
restrictions
on
what
I
can
do.
I
can't
trash
the
map
that
I
lent
out
to
them.
So,
let's,
let's
see
the
code
and
I
think
this
will
make
more
sense.
Here's
a
little
fragment
of
code.
It
begins
just
like
the
other
one.
It
creates
a
map,
but
the
next
thing
it
does
is
it
takes
the
address
of
a
local
variable.
A
So
if
you
know
C
you'll
know
the
ampersand
operator,
but
if
you
don't
what
that
basically
does
is
it
makes
a
pointer
right
into
the
stack
right,
and
this
is
what
a
borrow
is.
So
if
that
sounded
a
little
abstract
before
you
know
more
concretely,
a
borrow
is
taking
the
address
of
something
basically
and
the
lifetime
of
this
borrow.
A
That
span
of
time
in
which
the
data
is
borrowed
is
going
to
be
from
the
point
where
you
took
the
address
to
the
point
where
you
that
variable
went
out
of
scope,
the
variable
B
so
basically
till
the
end
of
the
block
and
the
compiler
is
going
to
check.
You
know
it's
not
it's
not
legal
to,
but
to
lend
something
out
for
longer
than
it
exists
altogether.
So,
for
example,
if
we
tried
to
borrow
this
hash
map
for
a
span
of
time
that
was
bigger
than
this
current
function,
that
would
be
an
error.
A
We'll
see
that
later,
getting
ahead
of
myself
but
taking
the
address
noise
is
one
kind
of
borrow.
It
can
also
be
a
little
bit
more
indirect,
like
I
told
you
that
in
C++,
when
you
fetch
something
from
a
map,
you
get
a
pointer
directly
into
the
map.
Well,
in
rust,
the
same
thing
happens
if
I
call,
if
you
look
I
changed
it.
If
you
call
em
get
that's
going
to
make
a
pointer
right
into
the
map
data
right-
and
this
is
actually
a
kind
of
borrow
as
well.
A
It's
the
same
exact
thing
basically
I
took
the
address
in
the
first
case,
I
took
it
over
the
m
variable.
In
this
case
it
took
it
of
some
data
that
the
variable
m
owns,
but
either
way
we've
basically
borrowed
the
map
and
yeah
do
I
have
a
little
thing
what's
going
on,
okay,
anyway,
so,
let's,
let's
see
now
what
does
it
mean?
So
what
I
said
that
there's
the
lifetime
of
the
borrow,
so
the
map
is
considered
borrowed
until
the
end
of
the
block?
What
does
that
mean?
Really?
A
That
means
that
there
are
some
things
we
can't
do
with
the
map
anymore
right
kind
of
like
our
book.
So
one
thing
we
can't
do
well,
this
isn't
with
the
map,
but
one
thing
we
can't
do
is
return
that
pointer
that
borrowed
pointer
out
to
our
caller
we'll
get
an
error
here,
and
the
reason
is
this
because
that
would
exceed
the
lifetime
of
the
borrow.
We
only
lent
it
till
the
end
of
the
block,
so
you
can't
just
have
that
pointer,
go
off
and
escape.
A
That
would
break
the
whole
idea
of
borrowing
when
you
borrow
something
you
have
to
give
it
back
basically,
and
this
would
be
not
ever
giving
it
back
so
we'll
get
a
compilation
error
and
that's
exactly
the
bug.
I
showed
you
with
C++
in
the
beginning
right,
but
there
are
some
other
things
we
can't
do
it.
A
It
would
be
bugs
like
we
can't
call
that
function,
take
and
give
it
the
map,
because
that
would
actually,
if
you
recall
that
I'll
free
the
map
and
then
we
have
this
pointer
into
freed
memory
and
that's
bad,
but
that
won't
be
allowed
either
because
that's
transferring
the
map
and
the
map
is
considered
borrowed
and
we
can't
transfer
something
while
it's
borrowed.
So
we
get
an
error
there
too.
A
So
basically,
the
memory
management
strategy
is
I
mean
that
about
sums
it
up.
Essentially,
you
have
for
every
data
structure
and
owner
it
moves
from
place
to
place
and
the
owner
can
free
it
or
they
can
just
keep
passing
it
along,
and
then
you
can
take
these
temporary
references
and
while
something
is
borrowed,
you
can't
free
it,
and
you
also
can't
have
that
reference
get
used
for
an
indefinite
period
of
time.
It
always
has
to
be
blocked
by
some
specific
lifespan.
A
All
right,
so
the
next
thing
I
want
to
talk
about
is
parallelism
and
we'll
see
that
our
approach
to
parallelism
really
builds
on
that
ownership.
All
those
ideas
of
ownership
that
I
just
talked
about,
but
I,
think
everybody
kind
of
knows
now
that
parallelism
is
important
and
we
can't
ignore
it
anymore
and
there's
some
graphs
that
go
like
this
and
blah
blah
blah
and
Moore's
Law.
A
So
if
we
can
all
agree
on
that,
then
I
can
say
that
we
also
all
know
that
parallelism
is
pretty
hard
right
like
if
you
think's
getting
your
memory
management
stories.
Sound
is
hard.
Parallelism
is
even
harder
and
so
it'd
be
really
good.
If
we
didn't
have
to
worry
about
some
of
the
nasty
bugs
that
come
with
it,
particularly
data
races
and
what
a
day
race
is
for
those
of
you
who
don't
know
is,
let's
go
basically,
it's
two
threads
writing
to
the
shared
memory.
It's
not
the
technical
definition,
but
it's
pretty
close.
A
So
if
you
imagine
I
have
these
two
guys
and
they
these
two
stick
figures,
and
they
both
have
the
same
book.
You
know
if
they
try
to
write
on
it
at
the
same
time,
they're
just
going
to
get
some
gibberish
and
it's
going
to
be
a
mess
and
what
we
want
to
do.
Then,
if
you
have
a
successful
project,
is
you
don't
allow
that
to
happen?
A
And
you
can
do
that
either
by
not
writing
to
the
book
at
all
just
reading
it,
that's
pretty
good
or
you
can
take,
turns
what
a
lock
is
for
right,
basically
say:
okay,
I'm
gonna,
write
to
it
now
and
the
other
guy
says:
okay.
Now
it's
my
turn
in
the
lock
make
sure
that
those
turns
everybody
plays
fair.
The
problem
is
it's
just
like
memory
management,
that's
really
easy
to
say
all
right.
A
That
sounds,
it
doesn't
sound
so
hard,
but
in
fact,
if
you
have
8
million
lines
of
code,
it's
pretty
hard
once
in
a
while.
You
forget
that
some
memory
is
shared
or
you
don't
realize
it's
shared
at
this
particular
moment
in
time
or
whatever
and
or
worse
it
was
fine,
but
then
you
quit
the
company
and
some
other
buddy
comes,
and
he
doesn't
know
what
what
what
Sheridan
was
not,
and
he
makes
a
mistake.
So
basically,
we
would
like
to
do
better
right.
A
So
if
we
go
back
to
our
control
and
safety,
if
we
have
shared
memory,
this
is
the
control
option
right
and
it's
great,
but
there's
really
no
way
to
avoid
these
bugs
except
being
really
really
careful,
and
if
we
go
the
other
way.
We
have
these
things
like
actors,
which
are
also
really
nice
when
they
work
and
what
they
basically
say
is.
Let's
avoid
data
race
is
the
easy
way.
Let's
just
say
you
don't
have
shared
memory
at
all
voila,
you
know
problem
solve,
we
can
all
go
home,
but
sometimes
that's
not
enough.
A
Sometimes
you
do
want
shared
memory
for
performance
or
whatever.
So
what
were
you
saying
in
rust
is,
let's
start
with
the
actor
idea?
Let's
say
most
of
the
time
we
don't
have
shared
memory,
because
that's
actually
pretty
good
and
it
gets
you
pretty
far,
but
when
you
do
need
it,
we
allow
shared
memory,
but
only
if
you
are
these
safe
mechanisms,
the
guarantee
that
you're
you
know
taking,
turns
or
guarantee
that
you're
only
reading
and
so
forth.
So
here
is
my.
You
know:
stick
figure,
explanation
of
how
it
works
and
we'll
get
to
the
code.
A
Basically,
like
I
just
said
the
default
is
that
you
don't
share
memory.
So
if
I'm,
if
there's
one
thread
here-
and
it
has
two
books
that
it's
working
with
and
then
another
thread
starts
up
and
we
can
transfer
some
of
that
memory
over
right,
and
this
is
that
same
notion
of
ownership
that
I
just
talked
about
so
instead
we're
disabilities,
giving
that
thread
unique
access
and
similarly
we
can
use
this
idea
of
messaging
I'll
show
you
in
a
bit,
but
basically
you
can
create
data
structures
and
then
send
them
back
and
the
same
works.
A
The
same
way.
The
memory
is
always
transferred.
Nobody
ever
has
the
same
data
at
the
same
time,
and
so,
let's
take
a
look
at
some
code.
This
is
the
code
to
start
it
starts
by
creating
a
hashmap,
and
then
it
calls
spawn
and
what's
spawn,
that's
a
little
library
routine.
That
starts
a
new
thread
and
it
takes
as
argument
this
thing
called
a
procedure.
If
you
know
what
a
closure
is,
a
procedure
is
kind
of
like
a
closure.
It's
a
function
body,
bundled
together
with
all
the
data
that
that
function
is
going
to
use.
A
The
difference
is
between
a
standard
closure
and
a
procedure
is
that
a
procedure
really
owns
that
data,
so
nobody
else
has
it,
and
so
basically
it
looks
through
finds
the
local
variables
that
appear
inside
this
procedure
body
and
it
moves
them
into
the
child
bed.
So
let's
do
my
favorite
graph
here
just
know.
A
From
a
class
well,
it
is
kind
of
like
a
class
actually
with
a
single
method.
Essentially,
but
like
call
no,
it's
basically
yeah.
It's
like
a
class
with
a
single
method.
That's
another
way
to
look
at
it,
so
you
have
here.
We
start
out:
we've
created
this
hash
map
and
then
we're
going
to
call
spawn-
and
this
is
the
body-
that's
the
body
of
the
procedure.
I
showed
you
just
kind
of
pulled
apart,
because
it's
going
to
be
a
different
thread
and
the
point
is
the
child
task.
A
A
I'll
go
through
this
fast,
because
I'm
running
a
little
short
on
time,
thought
I
had
a
little
more,
but
that's
alright.
This
is
another
useful
thing
that,
for
example,
or
long
has
that's
really
handy-
is
this
ability
to
send
messages
between
threads
while
still
maintaining
no
shared
memory,
and
it's
basically
like
a
pipe
in
UNIX
right.
So
you
create
this
channel
import
pair
and
they're
kind
of
quantumly
entangled
so
that
anything
that
you
send
to
the
channel
ownership
transfers
over
to
the
port,
and
you
can
use
this
to
communicate.
A
A
A
The
channel
in
the
port
are
split
across
the
two
threads
and
now,
when
at
some
point
later
that
child
task
should
execute,
it
can
create
a
message
and
it
can
call
this
send
routine,
which
is
going
to
transfer
them
ownership
of
the
message
out
of
the
child
into
the
port
and
then
later
very
synchronously
executing
when
the
receive
function
is
called
it'll
transfer
the
message
over
from
the
port
into
the
parent.
So
you
see
that
we
sent
a
message,
we
move
data
around,
but
we
never
actually
had
access
at
the
same
time.
A
So
what
if
we
did
want
access
at
the
same
time,
the
trick,
basically
as
I
said,
is
to
take
a
data
structure
that
is
to
take
that
memory
and
just
make
sure
that
we're
using
it
in
the
right
way.
So
we
would
either
like
the
memory
to
be
immutable
so
that
nobody
can
be
writing
to
it
or
to
make
sure
that
we
have
a
lock
and
not
just
some
lock.
We
should
get
but
a
lock.
A
We
have
to
get
so
that
we
know
we
don't
forget
and
the
way
that
works
in
rust,
I'm
just
going
to
talk
about
the
immutable
case
just
for
time,
is
basically
to
build
on
this
ownership
idea
and
introduce
some
library
types.
So
we
can.
This
is
actually
an
extensible
set
of
things.
These
are
the
two
we
have
now,
but
you
could
build
other
strategies
and
these
library
types
are
called
arts
which
stands
for
atomically
reference
counted,
I
kind
of
like
to
picture
them
as
like
Noah's
Ark
or
something.
A
But
basically
it's
a
data
structure
that
owns
some
data
and
then
uses
the
API
to
only
give
access
in
the
way
that
we
want
and
because
the
data
structure
owns,
because
the
data
is
owned.
Nobody
else
has
it
right,
that's
what
I
said
in
the
very
beginning,
so
here's
an
example:
I'll
I'll
skip
over
the
introductory
part,
but
we
can
get
to
this
state
where
we
have
two
threads.
They
each
have
an
arc
which
is
pointing
to
the
same
thing.
A
That's
the
kind
of
yellow
box
in
the
middle
and
inside
that
arc
is
a
hash
map,
along
with
a
ref
count,
and
the
ref
count
is
two
because
there
are
two
of
them
and
you
see.
Multiple
threads
have
access
okay,
so
the
parent
thread
can
can
use.
Basically,
the
only
method
that
arc
offers
is
this
thing
called
get
and
get
is
going
to
create
a
pointer
at
the
data
that's
inside
the
arc,
and
it's
going
to
return
it
as
a
temporary
immutable
reference.
A
This
is
borrowing
but
borrowing
the
contents
of
the
arc,
essentially
and
now,
because
that
reference
is
immutable.
If
I
tried
to
insert
into
the
hash
map
I'm
going
to
wind
up
with
a
type
error
because
I'm
trying
to
mutate
something
that's
immutable,
but
I
can
fetch
things
out
of
the
hash
map.
That's
just
fine,
so
that'll
create
a
pointer
right.
A
So
that's
the
RUS
strategy
in
the
nutshell
is
that
we
start
out
with
a
basis
of
no
shared
memory,
using
ownership
to
move
things
from
place
to
place
and
then,
when
you
do
need
sharing,
for
whatever
reason
we
build
up
a
library
of
safe,
essentially
containers
that
encapsulate
some
protocol
like
read-only
access
or
acquire
a
lock
and
so
forth.
Okay,
so
that's
all
pretty
good,
but
sometimes
you
know
it's
not
enough.
Sometimes
we
got
to
get
break
the
rules
a
little
bit.
A
We
you
know,
for
example,
some
of
you
might
have
noticed
that
I
said
all
data
has
one
owner,
I
said
that
a
lot
actually
and
then
I
showed
you
this
arc
with
two
owners
and
a
reference
count
and
I
kind
of
didn't
I
kind
of
papered
over
that.
But
you
know
that's.
You
might
be
wondering
how
that
works.
Well.
The
answer
is
that
the
implementation
of
arc
bends,
the
rules
it
uses
these
things
called
unsafe
pointers
and
unsafe
blocks,
and
an
unsafe
block
looks
kind
of
like
that.
A
It's
got
some
code
and
the
word
unsafe
and
what
it
means
is
hey
hold
on
I
got
this.
You
know
you
don't
have
to
check
this
code
very
carefully.
You
can
just
trust
me.
So
basically,
the
compiler
will
will
suspend
the
rules.
That
will
let
you
do
things.
If
it's
it's
essentially
a
different
syntax
for
C,
more
or
less
you
know
you
can
copy
pointers,
you
can
make
aliases
and
the
idea
is.
A
So
essentially,
what
we're
trying
to
do
here
is
give
you
the
means
to
build
new,
safe
abstractions
and
by
safe
I
mean
even
if
the
caller
does
some
goofy
stuff,
like
calls
all
the
methods
in
all
the
wrong
order,
it
still
shouldn't
crash.
It
still
shouldn't
cause
data,
races
and
so
on.
So
something
like
arc
that
I
showed
you.
That
has
exactly
one
method
that
gives
you
an
immutable
reference.
That's
a
safe,
API,
there's,
really
nothing!
You
can
do
with
that.
A
That
will
break
any
rules
and
we
use
this
sometimes
because
we
need
better
performance,
so
there
might
be
some
little
method
like
operating
on
a
vector
or
something
that
gets
called
ten
thousand
thousand
times,
and
we
can
write
it
in
a
more
efficient
way
if
we
can
bend
the
rules.
Okay,
that's
a
good
trade-off.
We
can
read
it
very
carefully
and
that's
fine
or
we
can
build
new
things
like
arcs
and
the
task
library
itself
for
that
matter.
A
So
that's
about
it.
Basically,
in
short,
I
guess
that,
as
I
said,
the
one
message
I
want
you
to
take
away
is
that
rust
is
kind
of
an
opinionated
version
of
C++.
You
know
it's
like
take
all
the
things
that
you'd
use
to
do
in
C++,
but
do
them
in
a
particular
way
kind
of
like
a
strict
code.
Reviewer
and
the
thing
you
get
out
of
this.
A
A
Right
yeah,
so
the
question
is
basically
rust
is
changing
really
fast
and
how
can
I
stay
on
top
of
those
changes
right
and
that's
a
good
question
and
I
thought.
The
answer
is
twofold:
one
is
we're
going
to
slow
down
so
it's
it's
been
a
long
long.
Road
and
I've
been
working
on
this
for
two
years
now
and
it's
been
been
a
project
for
longer
than
that
and
we've
done
a
lot
of
iteration,
but
we're
kind
of
happy
with
what
we've
got.
A
Now,
though,
we
are
doing
some
we're
paying
off
some
technical
debt
kind
of
like
manage
pointers,
doing
some
changes
that
we've
postponed
for
a
while
and
saying,
let's
get
them
done.
The
goal
is
that
this
year
we
should
release
a
stable
candidate
that
has
kind
of
a
core
language
that
won't
be
changing
any
more
and
build
on
that.
A
The
I
think
that
they're
I
don't
know
that
there
is
a
good
central
source
of
information
for
for
tracking,
except
for
the
IRC
Channel,
for
asking
questions
and
there's
like
this
week
in
rust.
But
it
would
be
a
good
thing
to
create
is
the
truth,
but
hopefully
it
will
be
less
and
less
necessary,
essentially
yeah.
A
A
Well,
things
like
data
races
and
so
forth
are
much
harder
to
avoid,
but
nonetheless
it
is
true.
There's
some
truth
to
say
that
C++
has
all
these
tools
to
build
abstractions
and
if
you
are
very
rigorous
and
you
use
those
correctly
and
only
those
you
know,
then
you
can
still
get
a
lot
of
the
benefits
of
rust.
Rust
is
kind
of
a
nicer
from
my
opinion,
syntax,
on
top
of,
though
you
know
taking
note,
taking
those
strategies
and
putting
making
a
language
out
of
them
rather
than
making
it
a
particular
way
of
using
C++.
A
The
question
was:
can
you
implement
this
as
a
standard
C++
compiler
like
a
lint,
essentially
right
and
I-
think
the
answer
is,
you
know
some
of
it?
Yes,
it's
kind
of
the
same
as
before
you
could,
but
some
things
are
a
lot
harder.
I
mean
aliasing
relationships
in
particular
are
notoriously
hard
to
track
down.
So
I
think
you'll
find
that
you
could
do
that.
You
won't
be
able
to
compile
existing
C
programs
with
that
because
they
weren't
written
with
that
convention
in
mind,
but
yeah
that
would
be
an
option.
A
B
A
Okay,
so
the
question
is:
can
I
can
I
intermix
different
kinds
of
memory
like
m
map
and
so
forth?
And
the
answer
is
absolutely
yes,
that's
one
of
our
big
goals
is
to
support.
Essentially
we
borrowed
the
term
from
C++
but
kind
of
smart
pointers,
and
these
are
basically
different.
These
pointer
types
can
manage
memory
in
different
ways,
so
we
have
things
like
an
arena,
for
example
that
allocates
a
big
block
of
memory
and
then
doles
it
out
and
then
freeze
it
all
at
once.
A
You
can
implement
those
kind
of
api's
and
you
can
implement
them
safely
for
the
most
part.
I,
don't
know
you
know
what
specific
use
case
you
have
in
mind
for
calling
a
map.
Certainly
you
can
call
MF
and
get
back
some
raw
pointers,
making
sure
that
it's
safe
is
a
little
trickier,
but
I
think
it
would
be
booble,
oh
well,
yeah
sure
to
map
an
input
file
or
something
yes,
that
you
could
certainly
do
that
right.
I
mean
I.
A
Think
if
you're
well,
I
think
if
you
call
n
map-
and
then
you
have
this
pointer-
that's
represents
a
file.
You
know
there's
some
you'll
have
to.
You-
have
to
sometimes
work
a
bit
to
make
sure
it's
safe.
If
you
really
want
that
I
mean
you
can
take
risks
yourself.
It's
your
project
like
you
could
just
pass
that
pointer
back
and
then
hope
that
nobody
calls
em
on
map
right,
but
you
can
also
do
things
like
have
an
object
with
a
destructor
that
calls
em
on
map
and
to
actually
get
access
to
the
pointer.
A
C
C
A
A
However,
we're
also
working
on
that
servo
project
I
mentioned
earlier,
which
is
kind
of
a
rewrite
of
the
browser,
and
then
there
are
a
lot
of
independent
projects
that
I
don't
even
have
a
full
handle
on.
There
are
even
a
few
people
putting
it
into
production,
which
I
think
is
interesting
because
we're
we're
still
making
some
changes
but
they're
willing
to
keep
up
you
know
so
so
that's
alright
good
for
them.
Yeah.
D
A
A
Yeah
and
then
maybe,
oh,
that's
fine!
Go
ahead
right!
That's
a
good
question!
I'm
surprised
it
took
this
long.
Actually,
so
I'll
start
out
by
saying
I
think
go
is
an
excellent
language,
we're
both
kind
of
targeting
in
some
sense,
similar
things,
but
in
some
sense
very
different.
So
goes
at
least
initially
I
don't
know
if
they
still
do
call
themselves
a
systems.
Language
and
Russ
calls
itself
a
systems.
Language
I
think
the
systems
that
we're
talking
about
are
kind
of
different
I
mean
I,
think
go
more
or
less
falls
on
that
spectrum.
A
That
I
talked
about
between
control
and
safety
that
trade-off
somewhere
between
Java
and
C++
I
would
say,
gives
you
a
lot
more
control,
but
it
also
does
have
things
like
data
races
and
so
forth
that
there
are
safety.
So
it
gives
you
more
control
in
Java,
but
still
less
than
C++,
and
it
emits
various
errors
and
that's
not
a
bad
thing.
I
don't
mean
when
I
say
you're
trading,
off
control
and
safety.
I
don't
mean
to
criticize
all
the
languages
on
that
line.
A
Question
is
how
much
comparison
have
we
done
for
the
performance
of
rust?
Obviously,
I
made
some
kind
of
strong
claims
about
control
and
efficiency
and
probably
a
little
stronger
than
we're
warranted
by
the
full
set
of
benchmarks.
I,
don't
have
to
show
you,
but
but
the
answer
is
that
I
think
we
we
have
every
time
we
do
some
comparison.
We
we
usually
find
that
the
code
is
pretty
much
pretty
comparable
to
C++,
although
there
is
often
some
most
micro
benchmarks
are
actually
benchmarking.
A
Some
library
and
our
libraries
haven't
been
optimized
that
much
so
a
lot
of
times
it'll
be
like
I.
Think
one
particular
one
I
remember
was
the
function
that
converted
numbers
to
strings
was
not
particularly
efficient
and
there
was
a
benchmark
that
basically
wound
up
calling
this
function
a
whole
lot
of
times
in
a
loop,
and
we
look
pretty
bad
until
we
improved
that
function.
But
you
know
in
terms
of
the
raw
what
kind
of
the
LLVM
code
that
we
generate.
A
I
didn't
mention
it,
but
we
build
on
LOV
M,
it's
pretty
comparable
to
C++
and
I.
Think.
There's
no
reason
that,
with
enough
tuning,
we
can't
have
performance
that
you
know
is
in
the
same
ballpark,
and
we
usually
do
I
should
say
at
this
point,
like
our
hash
maps
and
data
structures
are
pretty
fast
because
they
have
received
a
lot
of
attention.
Now.