►
Description
Nicholas Matsakis is a Senior Staff Researcher at Mozilla Research and a member of the Rust core, compiler, and language design teams. He has been working on Rust since 2011 and did much of the initial work on its type system and other core features. He did his undergraduate study at MIT, graduating in 2001, and later obtained a PhD in 2011, working with Thomas Gross at ETH Zurich. He also spent several years at DataPower Technology, a startup since acquired by IBM, working on the JIT compiler and networking runtime.
Follow us on Twitter: https://twitter.com/rustlatamconf
A
B
So
yeah
I'm
gonna
talk
today,
so
my
name
is
Nicolas
misaki's
I'm
gonna
talk
today
about
about
rest,
I've
been
working
on
rust
since
2011,
so
like
7
to
8
years,
I
think
that's,
probably
one
of
the
oldest
people
and
a
few
things
have
changed
in
that
time.
So
when
I
started,
the
project
was
in
a
repository
called
Graydon,
slash
rust
because
it
was
still
a
personal
project
to
some
extent
of
Graydon
horror,
and
there
was
the
big
warning
on
it.
That
said,
like
don't
use
this.
B
If
you
run
this
program,
anything
could
happen,
it
might
eat
your
laundry
I.
Think
that
wasn't
true.
Probably
that
was
unlikely,
but
you
know
that
was
the
point.
It
was
a
very
early
stages
and
in
my
personal
life,
things
were
a
little
different.
For
example,
I
had
my
daughter
was
just
born.
You
can
see
now
she
drew
these
pictures
you'll
see
some
more
of
her
pictures
throughout
the
talk.
So
this
is
a
picture
of
us
kind
of
because
it's
cute
wait
load
there.
That's
me
and
her
from
from
the
first
day
or
something
at
Mozilla.
B
That
was
the
old
offices.
We
had
a
big
dinosaur,
so
yeah,
so
I've
been
working
on
rest
for
awhile,
and
you
know
things
back.
Then
they
were
a
little
different.
I
went
looking
through
the
history
of
the
repo.
The
syntax,
for
example,
was
a
little
different.
This
is,
if
you
know
Russ
today,
you
would
recognize
this
more
like,
like
that.
B
That's
how
it
looks
now,
but
back
then
it
was
written
a
little
little
differently
and
we'll
see
that
there
I'll
go
talk
later
about
how
the
language
was
different
in
deeper
ways
too,
not
just
the
syntax,
but
these
days
you
know
rust
is
in
a
very
different
place.
So
this
is
a
chart
showing
the
number
of
packages
in
our
package
repository
and
it
starts
in
2015,
which
is
about
when
rust,
1.0
was
released
so
like
three
years
ago
and
I
think
I'm
not
mistaken.
B
You
can
kind
of
see
those
of
you
in
the
front
row
can
kind
of
see
a
little
bump.
Maybe
that
was
one
dot,
oh
maybe
it
was
I,
don't
know,
Alex
tells
me
no,
but
that's
okay,
I'm
gonna
say
that
it
was,
and
obviously
things
have
changed
right.
In
the
meantime,
we've
grown
a
lot
more
and
we're
starting
to
really
accelerate,
which
is
really
awesome,
and
not
only
that,
but
we've
also
started
to
see
a
lot
of
people
using
rust
in
productions.
B
You
saw
various
sponsors
here,
for
example,
I
think
the
first
production
user
was
Yehuda
Katz,
who,
if
you're
familiar
with
Ruby
on
Rails
or
Ruby,
you
might
know
him
from
that
context.
He
also
built
bundler,
and
you
can
see
that
you
know
way
back
in
2013.
He
started
using
rust
when
it
was
in
a
very
unstable
state.
So
this
was
like
two
years
before
1.0
we
were
changing
things
all
the
time
and
I
think
our
reaction,
when
he
said
he
wanted
to
put
rust
in
production,
was
kind
of
like
this
right.
B
It
was
like
what
are
you
talking
about?
That's
a
terrible
idea,
but
he
did
it
and
you
know
it
served
a
role
for
them
because
they
were
building
something
in
Ruby.
They
were
building
a
Ruby
on
Rails
kind
of
plug-in
and,
and
they
had
a
problem
that
it
was
most
of
it
was
fine,
but
sometimes
what
it
would
do
is.
B
It
would
monitor
your
Ruby
on
Rails
installation
and
your
server,
and
it
would
run
too
slowly
and
it
would
actually,
you
know,
not
just
monitor
it,
but
actually
be
slowing
down
and
causing
problems
sometimes,
and
that
wasn't
good.
So
they
wanted
to
rewrite
the
core
performance
parts
and
they
needed
an
another
language
to
do
it,
and
they
had
already
tried
to
tune
it
in
Ruby
as
best
they
could,
and
so
they
ended
up
choosing
rust
and
it
worked
out
really
well
for
them.
B
But
I
think
it
also
worked
out
really
well
for
us,
because
we
got
Yehuda
as
well
as
a
kind
of
influx
of
people
from
the
communities
like
the
Ruby
community
and
so
on.
It
brought
a
lot
of
new
ideas
to
rust
and
really
started
to
influence
it
right
and
you
who
taught
himself
ended
up
building
cargo
and
a
bunch
of
other
things.
So
it
was
good
for
both
of
us
and
since
then
there
have
been
a
lot
more
production
users.
B
These
are
kind
of
the
the
biggest
names,
I
would
say
the
most
household
names
you
might
have
thought
that
Mozilla
would
be
the
first
production
user,
but
actually
we
were
pretty
late.
We
kind
of
just
waited
and
said
I
think
most
the
rest
of
the
company
was
content
to
say.
Okay,
you
guys
just
tell
us
when
it's
ready,
we'll
let
you
mess
around,
but
there
are
a
bunch
of
companies
here
that
you
probably
recognize
and
if
you
go
to
our
website
or
check
out
the
sponsors
you'll
see
a
bunch
more.
B
So
that's
pretty
exciting
right
and
you
might
think
someone
who's
been
working
on
rust.
I
would
be
like
super
excited
about
this,
but
I'm
kind
of
a
cynical
negative
person
at
times,
I'm
also
I,
don't
project
that
way,
but
it's
true
and
I
and
I
think
to
myself
well
sure
they're
using
rust,
but
do
they
like
it
like
this
it?
That
would
be
better
right.
They
probably
hate
it,
but
they
know
that
it's
good
for
them,
but
actually
people
seem
to
kind
of
like
rust
right
and
for
me,
that's
really
exciting.
B
In
fact,
I
might
even
say
that
they
they
love
rust.
Sometimes
we
won,
after
all,
the
most
loved
award
two
years
in
a
row
at
Stack
Overflow
and
that's
pretty
cool
and
it
kind
of
got
me
thinking
about.
You
know.
Why
is
that
right?
So
this
definitely
makes
me
happy.
This
is
kind
of
alright.
Not
only
do
they
use
it,
but
they
actually
like
it,
but
but
why?
What
is
it
that
people
are
excited
about
and
I
thought?
B
That's
what
I
would
try
to
talk
about
today
to
kind
of
put
this
puzzle
together
right
of
what
what
are
the
pieces
of
rust
that
combine
to
make
it
a
kind
of
different
experience
that
people
are
interested
in
that
might
make
something
the
most
loved
language
or
and
so
forth,
right
and,
like
I,
said
I'm
a
little
bit
cynical.
So
when
I
thought
about
this,
the
first
thing.
The
word
that
popped
in
my
mind,
was
it's
probably
just
hype.
Probably
they
liked
it
cuz.
B
Everybody
else
says
they
liked
it
and
I
realize
now
that
this
slide,
like
this
movie,
is
probably
kind
of
old
and
people
don't
know
what's
going
on
here,
but
this
he's
doing
the
Macarena
in
case
you
can't
tell
which
maybe
you've
heard
of
it.
I
don't
know
anyway,
but
I
think
like
I,
don't
think
it's
just
hype
anymore
right,
I
used
to
think
that
and
maybe
in
the
beginning,
I
think
there
was
some
goodwill
and
we
had
a
lot
of
energy.
B
But
over
time
you
wouldn't
see
this
much
people
getting
excited
this
many
companies
picking
it
up
if
there
was
really
nothing,
nothing
underneath
it
so
I
think
it's
more
than
that,
and
so
maybe
then
it's
the
domain.
Maybe
it's
this
like
systems
programming
right,
which
I
think
a
lot
of
people
don't
even
know,
including
me,
actually,
very
precisely
what
that
is
I,
like
be
honest,
you
stripped
David
he's
the
person
who
invented
C++.
That
I
think
is
pretty
good,
which
is
systems.
Programming
is
like
programming
when
you
are
aware
of
your
resources.
B
Let's
say
when
resources
matter
when
it
matters
how
much
CPU
you
use
how
much
memory
you
use
that
sort
of
thing
and
you
know
I,
think
it's
a
really.
At
the
end
of
the
day,
though,
people
like
their
programs
to
go
fast
right,
that's
kind
of
definitely
true
and
rust.
Rust
tries
to
deliver
on
that
and
I
think
that's
a
big
part
of
our
appeal
right.
B
It
comes
from
C++
right
and
it's
this
idea
that
C++
has
a
bunch
of
key
aspects
of
its
language,
design
that
work
together
so
that
when
you
build
classes
and
you
build
new
layers
and
things
like
that,
like
you
have
iterators
and
hash
tables
and
vectors
they
perform
as
fast
as
they
would
have
done
if
you'd
written
the
code
in
a
lower-level
way,
if
you'd
written
the
code
kind
of
directly
in
C.
So
if
you
use
libraries,
you
don't
pay
a
cost
for
using
those
libraries
and
that's
that's
something-
that's
kind
of
unique
to
C++.
B
It's
not
really
true
in
languages
like
Java
or
JavaScript,
we're
adding
more
objects
on
adding
objects
on
top
of
objects
and
wrapping
other
objects
with
them
kind
of
increases.
Memory
usage
increases
the
amount
of
work
that
the
compiler
has
to
do
so
that's
part
of
it
I
think
and
that
it's
also
the
fact
that
Russ
doesn't
have
a
runtime,
which
means
there's
all
these
places
where
you
could
use
to
be.
You
could
only
use
C,
it
was
kind
of
the
lingua
franca
like
you
want
to
extend
your
Python
interpreter.
Well,
you
can
write
a
C+.
B
You
can
write
a
Russ
plugin,
so
that's
really
cool,
but
you
might
then
wonder.
Ok,
so
that
can't
be
the
whole
story,
because
if
it
were
just
the
performance
we
could
just
use
C++.
We
had
it
already
all
right,
but
C++
is
kind
of
like
this
rocket
a
little
bit
like
it's
super
powerful
and
it's
cool,
but
it
it
doesn't
always
go
the
way
you
expect
right
when
you
actually
put
it
into
production
and,
of
course
that
was
like
a
prime
motivator
for
rust
itself
right.
B
That's
fine,
but
there
are
a
lot
if
you
want
peak
performance
and
so
on,
it's
not
so
great
and
secondly,
it
didn't
actually
solve
all
the
problems
like
a
GC
language,
Python
or
Java,
or
something
you
still
have
null
pointers.
You
can
still
have
data
races,
so
you
solve
some
of
the
problems.
You
gave
up
some
of
your
control,
but
you
didn't,
you
didn't
solve
all
of
it
and
that's
where
the
rest
kind
of
tries
to
fill
this
gap
right.
B
We're
trying
to
have
all
the
control
or
all
the
runtime
and
none
of
the
problems,
and
mostly
we
succeed,
I
would
say
which
is
pretty
cool,
but
sometimes
I
found
that
you
might
think
well,
okay,
so
that
sounds
great.
Why
would
somebody
not
use
it
I
agree,
but
sometimes
type
systems
can
be
like
a
kind
of
a
hard
sell.
B
I
think
the
way,
basically,
the
way
that
we
solved
all
these
problems
is
by
not
using
something
like
a
garbage
collector
at
runtime,
but
by
doing
a
static
check
at
compilation
time,
and
so
we
checked
that
your
program
behaves
correctly
and
you
have
to
learn
how
to
work
with
the
type
checker.
So
there's
definitely
a
learning
curve
to
this
approach.
It
takes
longer
to
get
started.
You
have
to
learn
how
to
factor
your
programs
differently
and
that
can
be
a
bit
tough
right.
It's
if
you're
trying
to
ship
a
product.
B
So
let
me
give
you
one
example
from
Mozilla
where
this
was
true,
so
we
have
you
probably
can't
read
that
that's
okay,
we
have
recently
shipped
in
a
new
version
of
Firefox,
an
extension
that
lets
us
render
your
do
some
of
the
CSS
processing
in
parallel.
So
this
part
that's
called
selector
matching.
It's
part
of
the
process
of
displaying
a
web
page
right,
and
the
thing
about
this
problem
is
that
it's
it's
so-called
embarrassingly
parallel,
which
is
actually
a
technical
term,
and
it
means
like
it's
so
easy
to
paralyze.
It's
really
kind
of
embarrassing.
B
If
you
don't
do
it,
because
it's
just
a
big
bucket
of
tasks
that
can
be
done
in
virtually
any
order,
and
yet
this
bug
was
only
recently
closed
and
if
you
look
when
it
was
reported,
let
me
make
it
a
little
bigger
for
you.
It
was
reported
eight
years
ago
so
somehow,
over
over
eight
years
of
C++
people
like
really
knowledgeable
people
trying
to
do
this,
they
didn't
succeed,
even
though
it
was
an
embarrassingly
easy
problem
to
do
right
and
in
fact
we
tried
it's
not
for
one
of
trying.
B
B
B
You
structs,
maybe
you
have
fields,
some
methods
on
those
trucks
or
maybe
classes,
but
you
know
it's
not
it's
kind
of
it
captures
a
lot
of
what
you're
trying
to
do,
but
a
lot
of
times
you
run
into
situations
that
it
can't
describe
and
well
Russ
tries
to
do
is
add
a
lot
to
more
patterns
to
that.
So
you
can
describe
a
lot
more
things
and
describe
how
your
program
works
more
precisely.
B
B
If
it's
a
square
it
has
a
width
and
a
height.
If
you
have
different
sets
of
fields
depending
on
which
case
you
are,
and
then
you
can
do
things
like
match
across
them,
so
you
say
well
let
me
look
at
that
shape.
If
it
was
a
circle,
then
I'm
gonna
run
this
code,
which
is
computing
the
area
in
this
case
and
when
I'm
running
that
code,
I
get
access
to
the
field
radius,
but
I
don't
have
access
to
these
other
fields,
width
and
height-
that
don't
apply
in
this
case.
B
B
So
a
java
string,
it
might
be
a
string,
but
it
might
also
be
nothing
at
all
right,
whereas
in
rust,
if
you
have
a
string,
it's
really
a
string,
but
if
you
want
to
maybe
have
nothing
at
all,
you
can
use
something
like
option,
which
is
an
enum.
It's
a
generic
enum.
So
it's
based
over
some
type
T
in
this
case
it
might
be
string,
let's
say,
and
it's
either.
Yes,
that's
other
sum,
which
means
there
is
something
there
or
none
like
nothing
right,
and
that
means
that
the
type
of
your
variable
actually
reflects.
B
B
They
make
being
able
to
express
the
pattern
you
want
to
express
concisely
means
it's
nice
to
use
instead
of
annoying
right
and
there's
a
lot
of
things
like
fall
in
this
category.
I
think
enums
closures,
I,
don't
know
what
else
traits
and
generic
programming.
We
have
a
lot
of
features
that
they're
not
really
unique
to
rust.
B
They
kind
of
were
borrowed
from
other
languages,
maybe
tweaked
a
little
along
the
way,
but
they,
let
us
say
things
that
are
hard
to
say
sometimes,
and
that's
really
powerful
and
I
think
one
of
those
is
kind
of
outside
of
the
language.
But
it's
worth
mentioning
is
it's
just
cargo
itself,
our
package
repository
and
package
manager,
because
this
is
what
lets
you
take
some
random
piece
of
code
and
just
use
it
with
like
one
line
of
code
to
download,
build
and
configure
it
right
and
if
you've
ever
worked
in
C++.
B
You
know
that
that
didn't
used
to
be
the
case
with
system
software,
that
it
was
easy
to
reuse
other
things.
So
that's
that's
a
piece
of
it,
but
those
things
are
not
unique
to
rust
either
right.
There
are
the
things
we
borrowed
from
other
languages,
I
think
the
last
piece
of
this
of
the
type
system.
The
kind
of
most
central
piece
is
ownership
and
borrowing-
and
this
is
an
extension
that
really
is
in
a
way
unique
to
rust.
B
I
mean
we
borrowed
it
from
research
languages
that
are
out
there,
but
in
terms
of
and
adapted
it,
but
in
terms
of
mainstream
languages.
It's
it's
kind
of
novel
right
and
the
key
aspect
of
it
is
unlike
say
an
enum.
An
enum
is
a
different
version
of
struct
right,
a
struct
tells
you
what
data
is
there
and
what
you
can
do
with
it?
An
enum
also
tells
you
that,
but
it
has
some
more
flexibility.
Maybe
it's
one
of
two
different
kinds
of
data,
but
ownership
and
borrowing.
B
Let
you
describe
something:
that's
completely
orthogonal
another
aspect:
not
what
data
is
there,
but
who
has
access
to
that
data
and
what
permissions
do
I
have
and
that
lets
you
expand
the
scope
of
things
that
you
can
talk
about.
Let
me
give
you
some
examples,
but,
like
I,
want
to
kind
of
give
a
good
idea
for
what
it
feels
like
to
use
ownership.
What
does
ownership
mean
in
a
programming
language
I
think
we
know
what
ownership
means
in
real
life.
B
This
guy,
if
I
owned
something
it's
like
it's
mine
and
importantly,
it
is
not
yours
right.
It's
that's
the
key
bit
and
I
think
if
we
actually
look
most
programming
languages
that
are
out
there,
we
find
that
they're
pretty
good
at
the
mind,
part
and
they're,
not
so
good
at
the,
not
yours
part
and
that's
important,
all
right
and
actually
the
source
of
a
lot
of
problems.
So
let
me
walk
you
through
an
example.
This
is
using,
go
I'm,
not
picking
on
go.
It
could
be
any
language
find
ghost
syntax,
actually
quite
nice
for
this.
B
So
it's
a
good
example
language,
but
really
any
garbage
collected
language
has
this
pattern.
So
what
we're
gonna
walk
through
is
two
to
go
routines
which
are
two
threads
and
go
right
to
independent,
like
things
of
control
and
the
first
one.
Oh
here's
some
more
of
my
daughter's
pictures,
which
I
love
the
first
one
is
going
to
be
running
this
function,
foo,
and
you
see
that
the
first
thing
it
does
is.
It
creates
a
gift
right
and
it
puts
it
in
this
variable
regalo
and
okay.
This
is
a
struct.
B
It
has
some
value
and
then
what
we're
going
to
do
is
we're
gonna,
send
it
across
this
channel
over
to
another,
go
routine,
it's
very
excited
and
looking
forward
to
receiving
the
present,
but
even
though
we
sent
it
like
logically,
we
gave
this
gift
to
the
other
girl
routine,
but
I'm
gonna
draw
it
halfway
between
them,
because
really
we
kind
of
kept
some
of
it
for
ourselves
right.
We
still
have
this
variable
regalo
and
we
can
still
use
it.
B
Even
though
we
sent
this
gift
to
the
other
party,
and
there
may
be
thinking
that
it's
there
is
now
it's
kind
of
both
of
ours.
So,
for
example,
I
could
go
and
open
this
present
and
find
what's
inside,
and
maybe
it's
a
blueberry,
so
yeah
I
asked
my
daughter,
I
said
just
just
draw
whatever
you
want
to
know.
I'll
put
it
in
somehow.
So
this
is
what
I
think
this
is
what
I
got,
but
it's
okay.
B
So
so
then
we
could
open
it
and
now
that's
kind
of
a
problem,
maybe
for
the
other
side,
because
you
know
they
got
their
present
and
they
were
expecting
that
they
could
open
it.
They
wanted
to
open
the
president,
but
it's
already
open
because
we
did
it
and
now
we
have
this.
This
could
lead
to
a
crash.
This
could
lead
to
all
kinds
of
things
you
know-
or
maybe
it's
just
fine
I
don't
know.
But
the
important
point
is
this
is
what
we
call
a
data
race.
B
B
Sometimes
it
crashes
my
experience
is:
it
works
really
great
whenever
you're
running
your
tests
right,
but
it
doesn't
work
so
good
when
someone
else
is
running
the
testers,
but
then
it
will
crash
for
sure
and
I
mean
I
should
say
like
in
the
days
when
I
worked
on,
C++
I
definitely
spent
evenings
just
watching
a
movie
running
the
test
over
and
over
waiting
for
it
to
crash
exactly
once,
even
though
it
would
crash
consistently
for
the
customers
we
were
working
for,
it
can
really
be
frustrating
and
so
next
slide.
Thank
you.
B
So
what
went
wrong
here
kind
of
what?
How
did
we
get
in
this
situation
that
we
had
this
present
and
we
who
both
open
it
and
nobody
knew
who
was
supposed
to
open
it?
I
think
the
answer
is
that
there
kind
of
two
ways:
we've
we've
looked
at
this
problem.
There
are
like
two
things
that
went.
They
were
combined
to
cause
a
problem.
First,
we
had
mutation,
so
we
had
this
idea
that
we
could
open
the
present
and,
if
you're
a
functional
programmer-
or
you
might
look
at
this-
this
slide
before
and
say.
B
B
It's
just
an
immutable
object
for
all
time
that
never
changes,
but
it
can
create
an
open
present
from
it
and
then
there's
no
problem
because
norick
we're
both
expected
a
closed
present
and
that's
what
we
got
and
that's
true,
but
that
if
we
don't
allow
any
mutation,
we
kind
of
give
up
on
a
lot
of
efficiency,
which
is
what
we
were
trying
to
do
in
the
first
place,
and
we
kind
of
it's
hard
for
us
to
express
some
things
in
the
most
natural
way.
I
would
say
so.
B
B
You
just
have
two
gifts,
one
on
each
side
right
and
they
can
both
be
opened
independently
and
that's
okay
too,
but
that
again
costs
efficiency
and
again
it
might
be
something
that
we
wanted
to
sort
of
have
a
unique
resource.
Some
things
can't
be
copied
right.
So
what
Russ
does
is
take
a
different
approach.
B
So
nobody
else
can
be
surprised,
but
if
you're
going
to
share
the
gift
across
many
people
so
that
they
are
two
different
threads
have
access
to
it,
then
it
has
to
be
immutable,
so
nobody
gets
surprised,
and
that
turns
out
to
capture
a
lot
of
things
that
we
want
to
do
right.
So
if
we
take
that
exact
example-
and
we
run
it
through
in
rust-
we'll
see
it
turns
out
differently.
This
is
some
rust
in
tax,
so
we
have
a
function,
it's
called
main
and
it's
gonna.
It
starts
out
kind
of
the
same
way.
B
We
create
a
gift,
and
then
we
write,
channel
dot,
send
and
we're
gonna
send
our
regalo
across
the
channel
right
and
on
the
other
side.
This
is
what
a
channel
type
might
look
like
in
rust.
Okay,
so
it's
a
little
more
rust
syntax.
Let
me
just
walk
you
through
a
bit
of
it.
We
have
this
keyword
imple
that
declares
methods
in
rust.
B
Basically-
and
this
is
going
to
be
a
generic
method,
which
means
a
channel
in
rust
would
have
some
type
associated
with
it
that
says
kind
of
how
much
what
kind
of
data
we're
sending
and
so
on
the
other
point
when
we
take
the
argument
here
when
we
say
that
we're
taking
a
value
of
type,
T
and
rust.
This
is
where
the
difference
really
lies.
What
that
means
is
we
say
that
he
just
showed
me
a
slide
saying
I
only
had
10
minutes
and
I
was
like
really,
oh,
my
god
anyway.
B
B
So
that
means
that
this
gift
is
going
to
be
given,
from
the
left
hand,
side
to
the
right
hand,
side
and,
on
the
left
hand
side
here
when
I
pass
a
value
like
this
I
know,
I'm,
giving
it
away
I'm,
not
just
kind
of
giving
sharing
it
I'm,
actually
giving
it
to
the
other
side
completely.
So
I
can
draw
this
gift.
It's
moving
all
the
way
to
the
right
hand,
side
right
and
then
you
might
wonder.
Well
what
happens?
Okay,
so
I
just
I
use
different
words,
but
the
code
looks
the
same.
B
So
what
happens
when
I
go
on
and
I
keep
using
this
local
variable,
even
though
I
gave
it
away?
The
answer
is
the
compiler
tracks
what
you
gave
away
and
what
you
didn't
give
away,
and
you
get
an
error
message
right,
saying:
hey!
You
can
actually
see
pretty
nicely
here.
If
you
can
read
it,
I
don't
know,
but
it's
saying
on
the
first
line,
you
move
the
value
here
and
on
the
second
line,
then
you
try
to
use
it,
even
though
you
moved
it
right
and
so
that's
kind
of
the
key
essence
of
Russ
right.
B
So,
let's
step
back
for
a
second
I
just
walked
you
through
two
examples,
but
what
what
kind
of
just
happened
between
them?
Well,
what
happened?
Was
we
went
from
having
a
compilation
error?
Sorry,
we
went
from
having
an
error
when
we
ran
the
program
to
an
error
when
we
compiled
the
program
which
we,
which
is
a
really
important
difference.
I
think
systems
programming
has
a
reputation
also
parallel
programming.
They
both
have
a
reputation
for
being
very
difficult,
right
and
I.
B
Think
a
lot
of
the
reason
is
because
you
set
up
this
structure
that
seems
like
it
should
work
just
fine
right,
but
then,
when
you
actually
put
it
into
practice,
you
hit
problems
because
there's
a
lot
of
unwritten
rules
that
you
just
have
to
learn
or
they've
written
but
they're
not
enforced
right.
There's
a
lot
of
rules.
B
You
have
to
learn
and
understand
in
order
to
make
a
system
that
really
works,
so
there's
there's
kind
of
a
deceptive
learning
curve
that
happens
where
you
think
you've
got
a
system,
that's
working,
but
you
haven't
actually
learned
all
the
parts
it's
kind
of
like
this
right
and
so
in
contrast
or
what
so,
what
we
find
is
that
happens
again
and
again
is
that
it's
actually
pretty
easy
to
write
a
kind
of
high-performance
API
that
people
can
use.
The
problem
is
making
one
that
they
can
use
correctly.
B
That's
what's
really
hard
and
that's
where
a
rust,
where
ownership
and
borrowing
kind
of
changes,
the
balance
here
right.
So
in
short,
it
kind
of
makes
the
difference.
I
think
if
things
go
right
and
sometimes
they
do
you
wind
up
being
somewhere
like
this,
you
set
up
your
your
big.
You
try
to
paralyze
your
loop.
B
So
so
these
are
three
things
right.
We
have
these
zero
cost
abstractions
that
let
us
write
really
efficient
code.
We
have
these
modern
conveniences
that
let
us
express
patterns
more
concisely
than
we
used
to
be
able
to,
and
we
have
ownership
and
borrowing
that
let
us
actually
capture
permissions
and
what
I
think
happens
that
maybe
we
didn't
expect
in
the
beginning,
when
you
have
those
three
things.
Is
that
something
emerges
else
and
I
think
this
is
actually
the
thing
that
people
love
about
rust
if
they
love
rust.
B
If
there
are
any
libe,
if
people
have
examples
of
libraries
that
they
really
like,
basically
and
I
got
a
lot
of
answers.
I,
don't
have
them
all
in
these
slides.
You
know
these
are
just
a
few,
but
it's
kind
of
interesting
to
look
through
and
look
at
what
these
libraries
do,
and
it
gives
you
a
feeling
for
all
the
kinds
of
things
that
people
are
starting
to
do
in
rust
right.
So
you
have,
for
example,
well
Saturday,
which
is
even
kind
of
a
lot
of
base
libraries
like
Saturday
that
serialization
deserialization.
B
B
You
can
load
JSON
and
deserialize
it
into
a
rough
structure
in
just
a
few
lines
of
code,
and
it
will
be
as
fast
as
if
you
would
hand
written
the
code
for
the
most
part
right,
probably
faster,
because
it
would
be
hard
to
tune
it
that
bit
that
well,
and
we
have
things
like
rayon
that
lets
you,
which
I
was
involved
with
that
lets
you
paralyze
loops
very
easily.
Then
we
have
higher
level
things
like
backticks,
which
is
a
framework
for
web
framework
argument.
Parsing
specs.
Did
anyone
attend
the
games
workshop
yesterday?
B
B
If
you
have
these
great
primitives
at
your
disposal,
so
you'll
wind
up,
even
if
you're,
not
building
libraries
using
libraries
that
are
doing
better
than
they
would
have
done
because
they
had
stuff
to
draw
on
so
I'm
going
to
pull
out
this
last
tweet
because
I
think
it
kind
of
captures
what
I'm
getting
it's
recommending
a
create
called
diesel,
which
is
a
database
mapping
Creek,
and
it
says
here
that
it
takes
it
kind
of
bridges.
This
dichotomy
right
these
two
things
you
had
to
choose
from
before.
B
Either
you
had
a
low-level
database
connector
before
where
you
were
writing
sequel
kind
of
directly
and
it
was
very
error-prone
or
you
could
use
like
an
object.
Relational
mapper
thing.
There
was
very
high
level
and
had
all
these
layers
of
indirection
and
was
kind
of
slow,
but
it
worked,
and
these
will
kind
of
bridges
those
gaps
right
it
it
lets.
You
describe
the
schema
and
write,
queries
and
a
rust
like
syntax,
that
get
checked
but
executed
very
efficiently
a
map
write
down
and
that's
a
really
cool
thing
to
have
in
your
toolbox.
B
Okay,
so
there's
my
four
pieces.
I
think
this
is
the
answer
to
my
question.
What
do
people
love
about
rust,
I?
Think
it's
it's
the
sense
of
craftsmanship,
but
to
get
that
sense
of
craftsmanship.
We
had
to
have
these
other
pieces
all
come
together,
so
you
can
really
support
that.
But
you
know
if
you're
like
a
keen
observer,
you
will
see
that
I
said
this.
B
We're
always
focused
on
trying
to
find
the
best
answer,
as
I
wrote
here
and
not
just
on
winning
the
argument,
and
the
reason
that's
so
important
is
that's.
What's
allowed
us
to
kind
of
get
from
that
rust
that
we
had
in
2011
when
I
started,
that
was
really
a
different
language
for
the
rust
we
have
now
and
so
the
rust
we
had
in
2011.
If
you
look
at
it
from
a
technical
perspective,
it
didn't
have
most
of
the
story.
I
just
told
you
about,
we
didn't
have
zero
cost
abstractions.
B
We
didn't
have
ownership
and
we
had
some
of
ownership,
but
not
borrowing,
and
we
had
a
runtime.
We
had
a
garbage
collector
and
not
a
very
good
one,
and
you
know
it
just
kind
of
we
didn't
have
this
sense
of
extensibility.
We
had
a
lot
of
built
in
ideas
to
the
language
and
we
didn't
have
libraries
providing
those
ideas,
but
we
had
something
else,
though
we
had
something
much
more
important,
which
is
we
kind
of
had
the
right
goals.
We
knew
we
needed
it
to
be
fast
enough
to
replace
C++
like
really
fast
enough.
B
We
knew
it
had,
however,
to
also
be
safe
and
emphasized
correctness,
because
that
was
the
problems
we
had
and
we
knew
that
we
didn't
know
exactly
how
to
do
that,
but
that,
if
we
were
gonna
find
the
way
there,
we
needed
to
have
a
big
community
of
people,
contributing
ideas
and
concepts
right
and
so
to
make
sure
that
happened.
We
had
a
code
of
conduct
to
ensure
that
people
are
treating
each
other
nicely
and
we
had
a
culture
that
was
really
focused
on
exploring
trade-offs,
figuring
out.
Why
are
these
two
things
in
conflict?
B
Can
we
find
a
way
to
bridge
that
conflict,
or
is
it
really
irreconcilable
and
so
on
and
I
would
say
what
you
what
what
I?
If
you
look
over
the
history
of
rust,
you
will
find
a
lot
of
great
ideas.
This
is
a
partial
list,
but
what
you
will
not
find
is
one
person
responsible
for
all
of
those
ideas
and
actually,
if
you
look
at
this
list,
I
would
say
first
of
all,
they
were
all
introduced
by
different
people.
B
Sometimes
intersecting
sets
of
people
but
different
groups,
and
they
all
seem
kind
of
obvious
now,
if
you
know
rust
well,
you'll
like
now.
Of
course,
we
do
it
that
way,
but
actually
they
were
pretty
controversial
in
most
cases,
or
at
least
in
some
cases
very
controversial
when
they
came
out
right
and
they
certainly
weren't
obvious.
We
didn't
or
would
have
done
them
to
begin
with.
I
was
doing
research
for
this
talk
and
I
came
across
this
web.
This
blog
post
that
I
really
liked
by
someone
named
Jessica
Lord,
called
privilege,
community
and
open
source.
B
You
should
all
go,
read
it
the
URLs
down
there.
You
can't
read
it
of
course,
but
you
can
look
at
the
slides
later
and
see
it,
but
it
has
this
cool
quote
that
I
liked
that
I
think
captures
this
idea,
and
it
was
basically
saying
if
you're
trying
to
do
something,
that's
really
really
hard.
You
need
all
the
ideas
from
all
the
people
right
and
that's
I
think
the
spirit
that
I'm
going
for-
and
in
case
you
haven't
noticed
like
rust,
is
trying
to
do
something
really
hard.
B
Let's
just
take
a
moment
and
watch
this
lady.
Okay,
that's
really
cool,
so
so
we're
trying
to
do
something-
that's
maybe
not
quite
as
hard
as
that.
I
don't
know,
but
but
pretty
hard
right
when
we
started
out
with
rust.
If
you
think
back,
it
was
like
I
used
to
tell
people
what
is
rust
about
it's
about.
We
want
to
have
our
cake
and
eat
it
too,
right
which
in
English
is
like
the
definition
of
something
that
you
can't
do.
B
We
wanted
it
to
be
fast,
we're
going
to
be
like
C++,
but
also
like
Haskell
and
like
Java
right
and
all
these
things.
It
seemed
like
there
were
these
inexorable
trade-offs
and
we
wanted
to
bridge
them,
and
you
know
we
kind
of
did
it,
but
we
did
it
only
by
drawing
on
all
these
different
kinds
of
people,
and
the
other
thing
that's
worth
emphasizing
is
when
I
say
drawing
on
these
ideas:
it's
not
just
people
writing
code
or
when
we
think
about
open
source.
This
is
from
the
same
blog
post.
B
You
often
think
of
people
writing
code,
but
actually
there's
a
lot
of
skills
that
you
need
to
build
a
language
just
to
do
the
language
design
itself.
You
don't
want
to
give
the
language
design
to
a
bunch
of
type
theorists.
I.
Think
that
that's
the
worst
thing
you
can
do.
You
do
want
them
in
the
room,
but
you
don't
want
them
in
charge
on
all
on
their
own,
because
it
won't
be
very
usable.
You
want
also
teachers
and
users
and
users
from
different
backgrounds,
JavaScript
people,
Russ
or
well
yeah.
B
You
probably
want
Russ
people
now
back
then
I
wouldn't
say
that
C++
people
and
so
on
right,
and
you
also
want
people
from
different
domains
because
you'll
find
that
what
seems
like
the
perfect
solution
to
you
actually
rules
out
the
use
case
from
somebody
else's
situation
right
and
then
I
guess.
It
goes
a
little
past
that
too
right,
not
just
language
design.
But
if
we're
gonna
get
people
to
use
the
language,
we
have
to
teach
it
to
them.
B
B
And
so
a
lot
of
times
when
I
bring
this
up.
People
say
well
that's
great
to
have
a
lot
of
a
lot
of
ideas
and
stuff.
But
what
about
designed
by
committee
all
right?
What
about
the
danger
of
like
too
many
cooks
in
the
kitchen?
There's
all
these
great
expressions
for
when
you
get
too
many
people
around
and
the
design
gets
messed
up
and
I
I
kind
of
see
this
as
a
complicated
question
like
it's,
a
real
danger.
I
drew
this
picture.
This
is
from
The
Odyssey.
B
If
you,
if
you've
read
it,
I'm
Greek
so
I
have
to
like
include
at
least
one
Greek
myth
thing,
but
this
is
the
twin
dangers
that
all
these
sayers
had
to
face
right.
There's
this
whirlpool
and
that's
kind
of
maybe
that's
design
by
committee,
like
there's
a
real
risk
that
if
you
have
too
many
ideas,
and
you
can't
figure
out
how
to
put
them
together,
you'll
just
say:
let's
just
do
it
all
and
you'll
end
up
with
this
complicated
mess.
B
On
the
other
hand,
I
think
there's
this
other
danger
that
that
is
maybe
represented
by
what
could
go
wrong,
doesn't
necessarily
go
wrong,
but
what
could
go
wrong
with
a
like
dictator
for
life
kind
of
model,
which
is
that
you
can
just
ignore
people's
input
or
not?
Seek
it
right?
And
you
don't
know
about
what
you
don't
know
and
you
wind
up
with
this
system.
B
That's
not
able
to
really
solve
problems
as
well
as
it
could,
and
the
trick
is
to
somehow
steer
between
these
two
get
the
input
but
not
give
in
to
the
easy
solution
of
do
all
the
things,
but
try
to
resolve
it
into
something
that
is
coherent
but
addresses
all
the
use
cases.
And
if
there's
use
cases
you
can't
address,
then
you
should
do
that
consciously
right,
you
can
say
well
we're
not
going
to
handle
that
and
we
think
that's
okay,
because
of
X
Y
&
Z.
B
So
that's
the
trick.
It's
not
easy!
I
think
it's
something
that
we're
always
working
on
doing
better,
but
I
think
it's
the
right
way
to
go.
So
that's
the
full
puzzle,
I.
Think
of
what
what
makes
rust,
rust
and
now
I,
hopefully
am
getting
close
to
the
end
of
my
time
more
or
less,
but
I
want
to
take
the
last
few
minutes
to
talk
a
little
bit
about
the
future
about
what
I
think
is
up
for
rust
in
the
next
year
or
two.
What
are
our
big
challenges?
B
Coming
up
and
I'm
gonna
start
that
by
looking
back
at
the
past
at
this
point,
that
apparently
is
not
1.0
but
I'm
going
to
call
it
1.0
and
saying
think
about
what,
if
were
here,
involved
in
rust,
think
about
what
it
was
like
in
May
of
2015
right
we
had
a
core
language,
but
that
was
kind
of
it.
We
had
a
standard
library
that
was
like
90%,
unstable
and
not
allowed
to
be
used
on
our
stable
release
channels.
We
had
a
few.
B
B
In
the
meantime,
you
know
we
did
pretty
good
and
I'm
going
to
show
this
video
of
this
crazy
lady
again,
who
is
so
cool
and
I,
want
you
to
look
at
her
face
when
it
when
it
ends,
because
I
think,
because
I
think
that's
kind
of
how
we
we
should
feel
you
know
see
if
it
loads,
yeah,
okay,
I,
like
that,
it's
like!
Oh,
yes,
this
is
what
we
did.
You
know,
and
this
is
really
cool.
B
B
If
you
had
to
get
it
done,
you
got
it
done
it
didn't
matter
if
you're
doing
a
bunch
of
other
things
at
the
same
time
and
since
then
I
think,
we've
gotten
better
we're
like
not
doing
50
things
at
one
time
we're
doing
like
three
and
we
kind
of
have
a
system
for
how
to
do
it.
So
it
doesn't
seem
too
crazy.
It
almost
works,
but
the
thing
is
that
we're
leaving
that
phase
now
right,
we've
proven
that
rust
can
work.
B
B
You
know
this.
We
have
a
system,
we
know
how
to
solve
these
problems.
We
can
address
them
and
I
think
that's
what
we
need
to
be
focusing
on.
Most
of
all,
right
now
is
kind
of
building
and
organizing
all
the
things
that
we're
doing
and
figuring
out
how
we
can
do
that
best
and
in
the
process.
Also
doing,
of
course,
the
things
we
have
to
do,
and
so
that's
that's
what
I'm
personally
spending
a
lot
of
time.
Thinking
about
and
I'm
gonna
talk
a
little
bit
about
that
not
a
whole
lot,
but.
A
B
Think
it's
what
we
as
a
project
kind
of
some
of
our
biggest
challenges.
So
an
example
of
this
are
part
of
how
I
think
about
this
is
right.
Now
we
have
a
lot
of
things
if
you're
working
on
the
project,
there's
a
lot
of
state,
that's
in
people's
heads
right.
So
if
you
want
to
know
what,
but
let's
say
the
compiler
teams,
look
the
rust
the
rust
project
has
broken
up
into
teams,
and
these
teams
focus
on
different
things
and
there's
a
team
focused
on
the
compiler
and
that
team.
B
What's
going
on
and
finding
out
how
you
can
get
involved,
so
I
found
it
useful
or
I
find
it
useful
to
kind
of
step
back
from
the
project
if
you're
heavily
involved
and
think
about
what
would
it
be
like
if
I
came
to
this
and
I
didn't
know
anything
what
could
I
find
out
actually
and
so
on?
The
compiler
team
we've
been
working
on
this
right.
We've
been
adding
things
we
call
working
groups
which
are
like
groups
of
people
focused
on
a
particular
project.
B
We
have
a
repository
where
we
list
all
the
working
groups
and
they
have
meetings,
and
it
tells
you
like.
Oh
if
you
want
to
get
involved
in
building
this
feature
that
you
think
is
cool,
come
join
this
meeting
at
this
time
and
we'll
try
to
find
you
a
job
and
we're
working
on
adding
more
explicit
mentorship
pathways
and
levels.
B
So
sometimes
we
would
say
now
we
have
like
official
team
members
who
are
really
knowledgeable
and
then
everybody
else
right
and
we
would
like
to
have
more
levels
in
between
saying
this
person
has
been
contributing
for
a
long
time.
It
can
be
an
irregularly
mid-level
points
to
recognize
the
thing
that
they've
been
doing
and
one
of
the
things
I'm
coming
back
to
this
quote.
B
We
saw
this
quote
already
about
how
you
need
more
than
people
writing
code
and
one
of
the
things
I've
seen
from
doing
this
work
on
the
compiler
team
is
that
even
in
the
compiler
team,
which
you
would
think
of
as
like
the
co
deist
of
coders
or
something
there's
actually
a
lot
of
roles
that
are
not
directly
writing
code
that
we
really
need
and
I
think
we
should
be
speaking
to
people
and
encouraging
people
to
get
involved
in
these
ways.
And
it's
it's
things
like
organizing
meetings.
B
It's
things
like
testing
out
features
triaging
bugs
bisecting
bugs
some
of
these
roles.
We
have
ways
to
fill
some
of
them.
We
don't
and
I
think
what
winds
up
happening.
The
reason
when
I
showed
you
those
pictures
of
people
doing
a
hundred
things
at
once,
part
of
it.
A
big
part
of
it
is
stuff
like
this
right
is.
B
It's
done,
but
as
she
said,
so
that
people
who
have
only
a
little
time
actually
what
an
open
source
whenever
can
come
and
do
a
little
bit
of
each
of
these
tasks
right
a
little
bit
at
a
time
and
we
can
distribute
that
out
and
everyone
works
better.
So
one
thing
I
want
to
call
attention
to.
If
any
of
this
organizational
thing
of
the
idea
of
being
a
part
of
the
rust
organization
itself,
appeals
to
you
is
we're
starting
up
an
effort.
We
call
the
governance
working
group.
B
There
was
a
recent
announcement,
there's
a
link
at
the
bottom
that
I'm,
assuming
will
people
be
able
to
access
my
slides,
they're,
all
online?
You
could
click
it
there
and
or
you
can
just
search
our
internal
message
board.
But
the
point
of
this
working
group
is,
you
know
the
compiler
team
is
doing
some
set
of
things.
B
Other
teams,
lots
of
them
are
doing
other
things,
and
this
working
group
is
there
to
kind
of
talk
to
the
different
themes,
coordinate
amongst
them,
share
ideas
and
help
us
design
how
the
rust
organization
should
be
structured
going
forward
so
yeah.
If
you're
interested
in
that,
please
let
me
know
or
come
talk
to
me
afterwards
or
Florian
is
here
somewhere
but
anyway.
So
that's
what
I
got
to
say:
I
hope
you
learned
something
and
enjoyed
it,
and
thanks
for
listening
and
I'll
leave
you
with
these
awesome
picture.