►
Description
RustConf 2016 - Opening Keynote by Aaron Turon & Niko Matsakis
Aaron and Niko will deliver an update on the state of all things Rust. You don't want to miss it!
A
We're
about
to
get
started,
but
before
we
go
I
just
want
to
take
a
moment
to
say
thank
you
to
our
gold
sponsors,
skylight,
Mozilla,
Intel
chef.
The
guys
were
great.
We
would
not
be
able
to
do
this
without
you.
Thank
you
very
very
much
so
we're
gonna
talk
a
lot
about
what's
gonna
be
happening
over
the
next
year
in
rust,
but
before
we
do
that,
of
course,
I
want
to
look
back
about.
A
What's
happened
in
the
past
year,
sort
of
roughly
since
Russ
camp
last
year,
which
was
also
more
or
less
than
one
over
lease.
We've
all
been
working
pretty
hard,
and
a
lot
of
things
have
come
from
that.
So
we've
had
a
lot
of
progress,
for
example
in
the
library
when
we
first
released
100,
you
may
remember,
we
had
a
kind
of
minimal
but
stable
API
surface
we've
expanded
that
dramatically.
We've
added
175
new
features
to
the
stable
list
covering
all
kinds
of
areas.
A
So
you
can
now
really
use
the
standard
library
for
most
tasks
that
you
need
unstable,
which
is
great.
We've
been
building
a
lot
of
language
features
so,
for
example,
specialization
infiltrate.
The
question
mark
operator
now
the
macro
is
one
one,
RFC
and
I'm
sure
there's
a
lot
of
things.
I'd
forgotten
these
have
all
been
designed
gone
through.
A
The
RFC
process
have
been
implemented,
they're
all
on
nightly
now
at
varying
degrees
of
completeness
and
hopefully
they'll
be
making
their
way
to
stable
and
they're,
not
that
distant
future
and
in
the
meantime,
while
doing
that,
we've,
we
architected
and
re
implemented
a
lot
of
the
compiler.
So
we
added
a
new
internal
representation
which
we
call
Mir,
and
it's
now
on
default.
It's
now
the
default
back-end
on
nightly
it's
going
to
be
the
default
back
on
on
stable
and
a
release
or
I.
Think
it's
on
beta
I
can't
remember.
A
Yes,
it's
enabled
on
beta,
in
fact,
and
with
that,
we've
already
been
able
to
add,
for
example,
more
efficient
code
generation,
around
drop,
which
is
the
dynamic
drop,
something
we've
been
discussing
for
I,
don't
even
remember
before
we
got
it
to
work,
and
we
are
now
recently
released.
They're
kind
of
incremental
compilation
is
starting
to
make
progress
we're
in
an
alpha
period.
It's
working
except
we
have
a
lot
of
bugs
to
fix,
to
make
it
get
better
reuse
and
before
we're
willing
to
let
people
you
know,
but
we're
willing
to
recommend
that
you
use
it.
A
So,
finally,
we've
been
working
hard
on
cross
compilation.
We
have
a
rust
up
tool
now
that
lets
you
switch
tool
chains
very
easily
and
we
have
a
lot
of
tool
chains
available
and
you
can
kind
of
customize
it
for
directory
and
so
forth.
So
I
could
go
on
and
on
about
the
technical
details,
but
I
think
what's
most
exciting
is
that
in
the
year
since
we
released
it,
rust
has
remained
kind
of
a
language,
basically
a
language
that
people
love
to
use.
Right.
I
know
we
love
to
use,
and
that
is
really
great.
A
And
we
have
a
friends
of
rust
page
now,
where
people
who
are
in
industry
and
sign
up
or
I
guess
anyone
betting
money
on
rust
is
kind
of
our
catchphrase
can
sign
up
and
get
their
logo
on
the
page,
and
there
are
now
when
we
started
there
were
a
few
logos,
there's
now
35
and
you
can
kind
of
watch
a
video
here
where
I
word
Lee
scroll
through
the
list,
because
I
can't
figure
out
how
to
make
it
work
smoothly.
Someone
should
tell
me,
but
you.
A
So
pretty
cool
and
finally,
the
rust
community
itself,
as
evidenced
by
this
conference
right
here,
but
it's
starting
to
really
grow,
and
so
we
have,
if
you
believe,
meetup
comm.
We
have
14,000
people
attending
rust,
meetups
around
the
world.
We
have
a
new
community
team,
that's
working
on
mentoring
and
other
opportunities.
We
have
three
conferences
taking
place
this
year,
so
there's
rust
camp
here
and
then
another
in
Pittsburgh
in
Berlin.
A
C
Nico
yeah,
it
really
has
been
a
remarkable
year
and
before
I,
get
to
the
prognosticating
I
just
want
to
sort
of
echo.
The
theme
that
you
know
for
me,
the
most
exciting
thing
on
a
daily
basis
is
just
the
Russ
community.
The
level
of
you
know
passion
and
energy
and
kindness,
so
I
think
you
know
that's
what
keeps
me
going
today
and
it's
only
getting
better.
So
thank
you
all
for
that.
Yeah.
C
C
We
want
to
hear
from
them
here
what
kind
of
problems
they're
encountering
and
then
take
all
of
that
data
sort
of
try
to
digest
it
down
and
talk
as
a
community
about
what
are
the
biggest
problems
that
are
coming
up
and
from
that
build
out
some
themes
for
the
year
and
you
know,
sort
of
a
realistic
vision
of
one
year
from
now.
How
can
we
have
knocked
down
some
of
those
obstacles
to
using
rust,
so
this
process
is
already
underway?
C
Hopefully
many
of
you
have
already
participated
in
the
thread,
but
if
not,
there's
there's
a
thread
on
the
internals
forum,
that's
basically
starting
this
conversation
and
it's
going
to
go
for
most
of
the
month,
so
please
join
in.
In
the
meantime,
this
keynote
is
going
to
make
a
pitch
for
a
particular
part
of
that
vision.
That
I
think
is
really
important,
but
before
we
get
there
there
are
these
other
aspects
I
mentioned
before
about
you
know
it's
not
just
setting
out
the
vision,
but
it's.
How
do
we
execute
it?
How
do
we
communicate
it?
C
So
another
core
piece
here
is:
we
want
to
start
a
milestone
process
where
every
six
weeks,
they're
aligned
with
our
release
cycle,
we'll
be
setting
a
github
mile
stone
and
that
milestone
will
contain
the
work
that
the
various
teams
that
are
part
of
the
Russ
community
are
trying
to
do
toward
our
vision
all
right.
So
the
idea
is
at
least
every
six
weeks
we're
taking
a
step
back
looking
at
what
we're
trying
to
do
in
the
year
and
making
sure
we
have
a
concrete
increment
that
is
actually
taking
us
in
that
direction.
C
So
you
know
that's
good
on
an
organizational
level,
but
I
think
also
it
you
know,
I've
been
sort
of
saying.
Communication
is
really
important
here.
The
goal
is
anybody,
you
know
in
the
rest,
community,
so
I
think
a
lot
of
you
are
wrestling
enthusiasts
and
are
sort
of
up
on
things,
but
people
who
maybe
aren't
falling
so
closely.
It
should
be
really
easy
to.
You
know,
hit
up
the
rust
homepage
and
figure
out.
Where
is
rust
heading
what
work
is
going
on?
How
can
I
get
involved
and
help
rust
achieve
its
goals
right?
C
C
You
know
where
did
we
fall
flat
and
then
synthesize
all
of
that
into
a
kind
of
retrospective
that
we
can
release
to
the
world
so
every
year
we
want
to
put
out
sort
of
a
story
about
where
rust
is
going,
that
everybody
can
listen
to,
and
that
gives
a
really
coherent
narrative
and
that
should
be
looking
at
the
whole
ecosystem
right,
not
just
the
compiler,
not
just
the
language.
Okay,
so
that's
that's
the
big
picture
of
the
roadmap
process
and,
like
I,
said
the
keynote
is
really
going
to
focus
on
this.
C
This
vision
aspect-
and
you
know
I,
mentioned
that
we
want
this
to
be
driven
by
various
sources
of
data
and
one
of
the
big
ones
is
the
RUS
survey
that
the
community
can
put
together
a
couple
months
ago
and
you
know
I
think
we
were
all
blown
away
by
the
results
of
this
survey
and
a
lot
of
respects.
You
know
one
of
the
biggest
being
how
many
people
responded
right.
C
So
we
got
over
3,000
survey
responses
and
one
thing
that's
really
exciting
about
that
is
over
a
third
of
those
responses
came
from
people
not
yet
using
rust
right.
So
this
is,
if
you
put
this
all
together,
we
actually
get
a
pretty
informed
picture
of
the
obstacles
people
face,
whether
they're
using
rust
or
whether
they
would
just
like
to
use
rust,
but
you
know
aren't
able
to
for
one
reason
or
not.
So
let
me
go
through
some
of
the
challenges
that
sort
of
came
up
time
in
the
survey.
C
Okay,
so
far
and
away
the
biggest
challenge
we
would
see
is
the
learning
curve
right
this.
This
is
a
theme
that
was
repeated
in
one
in
four
responses
and
I.
Think
you
know
what
what
we
often
hear
when
we
talk
to
people
about
rust,
who
have
come
to
love
the
language
and
are
sticking
around
is
well.
The
first
two
or
three
weeks
were
pretty
rough
right.
I
had
to
like
fight
a
lot
with
the
Boro
checker.
There
was
a
lot
of
new
stuff
to
learn.
C
C
C
So
well,
well,
the
ecosystem
is
growing
quickly.
You
know,
there's
perhaps
more
we
can
do
to
focus
on
building
libraries
that
people
need.
Another
piece
is
just
overall--
maturities
and
not
just
in
the
library
space,
but
also
tooling,
compiler
performance,
debugging
and
so
on.
There's
there's
more.
We
can
do
one
thing,
I
think
that
surprised
a
lot
of
us
was
how
important
IDs
were
on
the
list
right.
C
So
if
you
look
at
all
three
thousand
responses,
it
was
like
one
in
nineteen,
but
if
you
narrow
to
the
you
know
a
third
or
so
of
people
not
yet
using
Russ
I
des
came
up
a
quarter
of
the
time
as
the
reason
that
they
were
not
yet
using
Russ
and
that's
really
interesting
and
I.
Think
in
a
lot
of
bigger
production,
shops
IDs
are
an
essential
part
of
people's
workflow
and
basically,
if
your
language
doesn't
have
a
good
IDE
story,
you're
just
a
non-starter
right.
C
There
are
lots
of
different
ways
to
look
at
productivity.
Lots
of
different
questions
you
might
ask
in
terms
of
is
a
language
productive
as
an
ecosystem,
productive,
but
I.
Think
the
biggest
obstacle
to
rest
today
is
its
productivity,
so
zeroing
in
on
that
a
little
bit
right.
There
are
some
aspects
of
productivity
that
Russ
gets
really
bright
today,
all
right.
So
if
you
need
to
write
a
piece
of
code
that
is
reliable,
rust
is
a
great
way
to
get
there
quickly.
C
If
you
need
to
write
a
piece
of
code,
that's
fast
rust
is
a
great
choice
for
that
right.
So
we
have.
We
have
some
good
strengths
here,
but
then
there
are
these
other
pieces
that
don't
really
sound.
Much
like
rust,
like
rust,
is
a
fast
way
to
get
up
to
speed,
writing
code
or
rust
is
a
great
language
for
prototyping
right.
These
are.
These
are
not
things
that
feel
very
true
of
rust
today,
and
it's
tempting
to
think
that
there
is
a
fundamental
trade-off
here
right.
C
Let
me
tell
you
about
trade-offs,
so
here's
a
slide
from
Russ
camp
keynote
last
year
that
was
trying
to
sort
of
sum
up
what
the
1.0
release
represented
in
terms
of
what
Russell
is
at
heart
and
I.
Think,
probably
all
of
you
have
seen
these
slogans
if
you've
been
around
in
the
rest
community,
but
each
and
every
one
of
these
things
represents
an
apparent
trade-off.
That
rust
has
been
able
to
overcome
right
before
rust
came
on
the
scene.
C
You
would
think
that,
well,
you
can
have
memory
safety
if
you
have
a
garbage
collector,
but
if
you
are
foregoing
a
garbage
collector
and
good
luck,
getting
a
memory
safe
language
well,
Russ
gives
you
both
the
same
right
or
if
you
want
to
do
concurrency,
especially
shared
state
stuff,
you're,
going
to
struggle
with
data
races.
Well,
not
anymore,
right,
Russ
lets
you
do
concurrency
of
all
kinds,
while
guaranteeing
data
race,
freedom,
all
right,
so
I,
think
a
big
part
of
the
spirit
of
Russ
is
having
our
cake
and
eating
it
too.
C
A
Alright,
so
with
that,
we're
gonna
go
through
some
of
the
different
teams
and
aspects
of
Russ
project
and
look
at
what
it
means
to
have
productivity
as
a
core
value
all
right.
So
when
it
comes
to
the
language
itself,
I
think
it's
as
Erin
said
it's
important
to
kind
of
look
and
realize
when
it
in
terms
of
being
productive,
while
also
having
code
that
runs
fast
and
is
reliable.
We've
done
a
pretty
good
job.
So
far,
right
I
mean
what
do
people
love
about
rust,
I'll.
A
A
But
in
this
version
it's
as
fast
as
some
C
code
that
has
a
little
pointer
and
skips
along
right
or
I
could
write
a
snippet
of
code
to
traverse
over
some
paths,
load
up
a
bunch
of
images
in
parallel
and
collect
them
into
a
vector,
and
it
just
takes
a
few
lines
of
code
and
again
I
could
do
that
in
some
other
languages.
But
I
made
a
mistake:
I'd
have
des
erases
and
maybe
1%
of
the
time
it
just
doesn't
work
the
way.
I
expect
a
few
images
get
lost.
Something
goes
wrong.
A
I
don't
have
to
worry
about
that
in
rust,
or
using
this
newer
work
on
futures
that
Aaron
and
Alex
have
been
working
on
and
also
Carl.
We
see
we
can
send
an
RPC
request
out
and
we
can
get
back
a
response
and
process
it
and
it's
a
few
lines
of
code,
but
it
performs
really
well
all
right,
so
here's
a
little
chart
that
they
put
up
in
a
blog
post
and
you
can
see
that
here
are
some
servers
that
the
different
kinds
of
server
is
implemented
in
different
ways.
A
Processing
hello,
world
requests
right
now,
if
I
told
you
don't
look
at
the
labels,
yet
I
said
which
of
these
do,
you
think
was
written
in
the
language
with
the
strongest
safety
and
reliability
guarantees
and
using
the
most
kind
of
idiomatic
abstract
code.
All
the
way
down
the
stack,
I
know
what
you'd
say:
you'd
say
the
fastest
one,
of
course
right.
No,
that's
not
what
we
normally
think.
We
normally
think
we
have
to
trade
one
or
the
other,
but
rust
has
really
turned
that
on
its
head.
A
What
we
find
people
saying
a
lot
and
what
I
feel
also
is
that
over
time,
right
with
the
language,
the
compiler
becomes
kind
of
like
a
trusted
pair
of
programmer.
You
just
kind
of
got
your
back
who's.
Looking
over
your
code,
helping
you
think
of
cases
you
might
have
overlooked
before,
and
so
even
in
this
simple
little
routine,
that
takes
in
an
optional
string,
which
is
the
name
of
a
user
I
guess
they
might
want
to
remain
anonymous
or
something
and
prints
it
out.
A
We
already
can
kind
of
see
some
of
that
all
right,
so
we
have
the
option
type
in
rust.
So,
instead
of
using
a
null
pointer
for
the
string
which
we
could
overlook,
we
have
to
notice
that
maybe
the
user
doesn't
have
a
name
and
we
have
to
customize
our
greeting
for
that
and
we
don't
get
some
kind
of
null
pointer
exception
and,
of
course
this
is
a
reference
to
an
option
of
string
which
is
the
key
to
the
whole
kind
of
house
of
cards.
A
We've
built
up
your
house,
the
Grasse,
the
wrong
way
to
work
key
to
this
beautiful
structure
that
we
built
up.
Basically,
you
know
it's
it's.
What
lets
us
have
say
not
need
a
garbage
collector
and
avoid
data
races
and
so
forth,
and
we
can
indicate
that
with
just
this
one
CID
jewel.
So
that
feels
good,
so
you
know
I
feel
pretty
good
about
these
codes
if
I
take
it
to
compile.
Of
course,
I
know
it's
gonna
work
right,
oh
wait!
A
No,
it's
not
gonna
compile
I'm
gonna
get
this
mismatched
types
error,
that's
a
little
bit
a
little
bit
aggravating,
but
that's
okay!
I
know
what
the
problem
is.
An
experienced
rust
programmer
I
just
have
to
put
this
star
here,
because
I
don't
want
to
match
on
the
reference
I
want
to
match
on
what
the
reference
refers
to
so
I
have
to
dereference
it
okay
good
now,
I
can
compile
the
code
and
everything's
fine
except
oh
yeah,
right
I
can't
move
out
of
borrowed
content
here,
that's
alright,
too
I'm
an
experienced,
rust
programmer.
A
I
know
the
thing
is
when
I
say
sum
of
n
I'm
taking
ownership
of
the
string,
that's
inside
the
option,
but
I
can't
do
that,
because
I've
only
borrowed
this
option,
so
I
need
to
borrow
the
string
as
well
and
I
write
ref
to
make
a
reference
to
the
string
and
now,
if
I
recompile,
it's
gonna
work,
and
so
this
is,
you
know
these
are
minor
annoyances.
When
you
know
what
to
do,
it's
still
a
little
bit
unfortunate
that
my
code
looked
prettier
before,
but
you
can
get
used
to
that.
A
But
if
you're
an
experienced
programmer,
that's
how
it
feels
right.
But
if
you're
coming
for
the
first
time
and
you're
still
trying
to
understand
what
ownership
and
borrowing
even
are,
this
could
be
a
total
game
changer.
This
could
be
like
I'm
just
going
to
walk
away
from
this
language.
I
can't
even
print
a
string
on
the
screen,
I'm
feeling
a
little
frustrated,
and
so
unfortunately,
I
think
there
are
a
lot
of
places
in
Russia
where
we
take
what
we
surface.
A
These
kind
of
small
details
constantly
write
to
the
user
and
you
and
you
once
you
learn
to
deal
with
them.
Any
one
of
them
is
not
a
big
deal,
but
they
can
kind
of
build
up.
So
here's
another
example:
a
pretty
common
one.
If
I
have
a
function
that
takes
a
string,
you'd
think
I
could
call
it
with
a
string
literal
right
that
seems
logical,
but
I
can't
because
string
literals
are
compiled
into
the
binary.
We
don't
have
to
free
them
afterwards,
so
they
have
a
different
type.
That
makes
a
lot
of
sense.
A
There's
a
really
good
technical
reason
for
that,
but
it's
not
necessarily
a
reason
that
I
care
about
any
particular
point
in
time
right
and
it's
particularly
not
a
reason
that
a
lot
of
new
users
are
familiar
with.
So
when
I
do
my
introduction
to
Russ
tutorials
literally,
the
very
first
thing
I
talk
about.
Is
this
okay?
Let's
just
talk
about
strings
for
a
second
and
it's
kind
of
a
shame,
because
it's
not
the
most
exciting
topic
to
cover
first,
but
so
a
similar
example.
I.
A
A
We
can
learn
those
rules,
but
when
we
come,
if
we
find
that
the
key
is
not
present
in
the
map,
we
still
can't
mutate
the
map
right,
because
the
checker
has
a
kind
of
lexical
notion
of
how
these
things
work
and
it
doesn't
understand,
control
flow
as
well
as
it
could
and
that's
something
that
can
be
very
frustrating
when
you're.
If,
once
you
understand
that
it
works
on
electrical
scope,
you
kind
of
get
it,
but
before
that,
you
might
think
you
don't
even
understand
the
whole
borrowing
system
when
really
what
it
is.
A
You
don't
understand
how
dumb
the
compiler
is
being
right
here
right,
it's
not
as
it's
not
seeing
it
the
way
you
see
it.
So
this
is
a
list
of
some
of
those
things
that
bother
me
or
that
I've
heard
about
you
probably
have
your
own
I'd
like
to
hear
what
I'd
like
to
hear
about
them,
actually
not
right
now
after,
but
so
I
think,
as
these
are
kind
of
all
of
these
exists
for
a
reason
right.
There
is
a
technical
reason
that
these
distinctions
exist,
and
sometimes
it's
very
important
to
have
control
over
these
details.
A
If
you
want
your
application
to
work
right,
but
it's
not
always
important,
and
it
would
be
really
nice
if
you
could
kind
of
choose
these
details
in
a
few
places
and
let
the
compiler
work
out
the
rest
of
them
for
you
right
and
then,
if
we
do
that,
I
think
what
we'll
find
is
that
this
trade-off.
We
see
where
it
feels
like
these
explicitness
and
total
control
are
at
odds
with
nice
ergonomic
programming.
We
can
kind
of
resolve
that
and
just
sidestep
it
and
have
it
not
be
an
issue
whatsoever
right
and
I.
A
But
if
we
look
back,
we
can
see
we
look
back
so
these
kind
of
galactic
power
examples
I
showed
before
we
can
see
that
a
lot
of
these
trade-offs
are
there
or
there
are
trade-offs
there.
That
we've
just
managed
to
hide
and
take
care
of
right
and
resolve.
So,
for
example,
the
biggest
one
I
think
is
closures.
Our
biggest
example
of
this
trend
closures
is
something
that
are
like
a
fundamental
building
block
for
abstractions
right.
A
A
You
have
multi-threaded
programming
where
the
closure
serves
as
the
body
of
a
thread,
and
you
have
things
where
the
closure
is
being
run
in
parallel
with
itself
many
times
like
in
the
loading
images
example
I'm
running
a
same
closure
for
every
image
and
the
RPC
is
a
little
bit
different
and
so
balancing
all
of
those
trade-offs
seemed
like
it
was
going
to
produce
this
kind
of
infinite
family
of
closures,
where
the
user
has
to
pick
just
the
right
thing.
But
what
you'll
notice
is
in
the
syntax?
A
And
in
these
examples
we
don't
really
see
all
those
trade-offs
to
play
right,
they're
there,
but
they're
not
right
in
our
face,
and
so
an
example.
A
specific
case
would
be,
if
you
look
at
this
variable,
my
socket.
This
is
something
from
the
environment.
It
has
to
be
either
borrowed
or
moved
or
moodily
borrowed
into
this
closure,
but
I
don't
have
to
say
that
right
we
figured
it
out
based
on
how
it's
used
in
the
closure.
If
you
moved
it
in
the
closure,
then
you
need
to
own
it.
A
So
if
we
look
kind
of
at
this
matching
case
that
I
showed
first,
you
could
imagine
that,
instead
of
requiring
you
to
say,
if
a
binding
is
a
ref
binding
or
not,
we
examined
how
the
binding
is
used
and
we
figure
it
out.
Just
like
we
do
with
closures.
So
you
might
say
this
print
'ln
is
doesn't
need
to
own
the
end.
It
can
just
printing
it
I
can
make
this
a
bar,
oh
right,
and
similarly,
instead
of
making
you
dereference
name
manually,
you
never
really
want
to
match
on
a
reference.
A
That's
not
very
interesting,
you're,
always
looking
at
what
it's
referring
to.
Maybe
we
can
just
skip
over
those
through
those
references
right
and
then
the
code
that
I
originally
wrote
would
have
worked
in
the
first
place,
but
it
would
have
worked
the
same
way
that
my
final
code
did
right,
just
as
efficient.
Similarly
here
with
the
string
literal,
if
we
could
extend
the
string
type
to
know
that
sometimes
it
is
containing
memory
that
comes
from
the
static
binary,
instead
of
being
always
a
heap-allocated
buffer,
then
it
wouldn't
have
to
free
it.
A
When
it
goes
out
of
scope,
then
we
could
allow
a
coercion
from
the
string
literal
type
to
string,
and
this
code
would
just
compile
and
better.
Yet
it
wouldn't
do
any
allocations
or
anything
like
that,
so
it
would
be
as
efficient
as
if
the
user
had
typed
antek
static
store
as
the
type
instead
of
capital
string
right.
It's
not
that
this
distinctions
going
away.
It's
just
that
we're
surfacing
it
differently
or
less,
and
so
finally,
this
example,
if
you've
been
following
rust
for
a
while,
you're,
probably
pretty
familiar
with
it.
A
The
map
example
and
here
I
think
we've.
We
have
a
kind
of
well-known
solution
to
this.
We
can
make
the
compiler
smarter
about
control
flow.
That's
been
a
long
time
coming,
it's
been
a
very
challenging,
but
now
the
mirror
is
in
place.
We've
kind
of
got
the
pieces
there.
We
have
everything
we
need
so
hopefully
we'll
be
seeing
that
and
again
where
you
can
kind
of
overcome.
This
see
me
make
these
rules
basically
just
simpler
to
work
with
right
and
once
we've
done
all
of
this
right,
the
language
we
have
not
given
up
any
reliability.
A
A
So
when
we
think
about
new
language
features,
we
tend
to
think
about
exciting
new
capabilities,
extending
the
language
in
some
way
that
do
something
it
can't
do,
and
those
are
important
things
and
we
have
to
keep
those
in
mind,
especially
if
they
sort
of
unlock
an
important
domain
for
us.
But
we
also
can
look
inwards
and
say:
okay,
what
what
are
we
doing
now?
How
can
we
tune
it
and
improve
it
and
make
it
more
productive
than
it
is
today?
So
all
right.
Thank
you
very
much
on
that.
But
let's
talk
about
libraries
thanks.
C
C
So
when
people
in
the
survey
talk
about
libraries
or
maturity
being
an
issue,
I
think
what
they
tend
to
be
talking
about
is
they
have
some
pretty
basic
need
for
library
to
do
some
work
they're
trying
to
do,
and
they
want
that
kind
of
library
to
exist
in
the
ecosystem.
They
want
to
be
able
to
find
it
easily
and
when
they
start
using
it,
of
course
they
want
the
library
to
be
of
high
quality,
and
you
know
what
I
think
high
quality
means,
of
course,
is
fast,
reliable
and
productive
all
over
again.
C
So
that's
a
fairly
basic
kind
of
goal
to
shoot
for
I
won't
spend
a
few
minutes
on
sort
of
each
of
these
dimensions,
highlighting
some
specific
things
we
can
do
to
improve
our
library
story.
Okay,
so
let
me
start
with
libraries
that
should
exist
or
should
exist
in
a
more
mature
fashion.
I
think
one
thing
that's
been
getting
a
lot
of
attention
recently.
That
people
are
very
excited
about
myself.
Included
is
rust
on
the
server
I
think
this
is
one
of
the
biggest
opportunities
we
have
for
getting
rust
into
production.
C
I
think
there's
a
lot
of
interest
from
really
high
scale,
internet
companies
and
using
rust.
You
know
in
exactly
the
cases
where
rust
has
a
lot
to
offer,
but
it's
also
a
huge
lift
right.
What
is
rust
on
the
server
even
mean
there's
so
many
different
subdomains
right,
so
we're
focused
right
now
on
building
the
foundations
for
this
story.
C
You
know
1.0
shipped
with
a
very
basic
IO
story
that
was
blocking
I/o,
which
is
fine
for
a
lot
of
things,
but
when
you
want
to
scale
up
to
a
big
server,
a
sink
IO
is
essential
right
and
so
we've
been
developing
story,
run
futures,
which
I
think
really
gets
at
the
fast
reliable
and
productive
trifecta
right.
So
there's
a
lot
of
excitement
around
it.
It's
very
new
stuff,
there's
gonna
be
a
lot
of
iteration
but
I.
C
Think
async
IO
is
gonna,
be
a
big
theme
this
year,
but
that's
that's
just
the
foundation
right,
just
having
an
async
IO
doesn't
mean
it's
easy
to
build
a
server
right.
So
on
top
of
that,
you
need
protocols,
you
need,
you
know,
HTTP,
you
need
to
talk,
thrift,
you
need
to
talk
to
databases
and
so
on
and
so
forth
right.
So
we
want
to
work
on
the
next
level
up
on
the
stack
and
there's
the
Tokyo
project,
which
is
focused
on
that
and
then
on
top
of
that
you
want
middleware
and
so
on.
C
So
there's
there's
potentially
a
whole
ecosystem
here
to
develop
and
I
think
it
really
deserves
to
be
a
major
area
of
focus
for
Russ
community
this
year.
Sort
of
related
to
that
and
one
of
my
favorite
topics
is
parallelism
and
concurrency
right.
I.
Think
Russ.
Concurrency
story
is
one
of
the
most
unique
things
about
the
language
right.
The
fact
that
you
can
freely
use
concurrency
without
being
terrified
of
data
races
all
over
the
place.
C
I
think
that's
really
cool
and
you
know
I
think
we've
got
some
good
examples,
but
I
don't
think
we're
fully
delivering
on
that
promise.
Today
and
the
reason
is,
you
know,
we
have
the
basics
in
the
standard
library.
You
can
sort
of
see
the
vision,
but
we
don't
have
that
fully
productive
story
across
the
board.
Yet
right.
C
We
can
do
maturing
that
part
of
the
ecosystem
this
year
as
well
for
a
lot
of
you
who
are
using
Rusted,
a
serialization
may
be
a
sore
spot
in
that
you're.
Probably
using
sturdy.
Sturdy
is
really
cool,
but
sturdy
traditionally
has
required
a
nightly
compiler
and
that's
all
kinds
of
painful
for
the
ecosystem.
So
we've
got
some
really
exciting
stuff
in
the
works
with
macros
1.1
you
may
have
heard
about
the
TLDR.
Is
we
want
to
get
dirty
unstable
as
soon
as
possible?
C
So-So,
looking
a
little
farther
afield,
you
know
I
think
there
are
more
specific
domains
where
rust
might
have
something
really
interesting
to
offer
that
we
haven't
as
a
community
sort
of
really
highlighted
or
put
a
lot
of
weight
behind
so
numeric
computation
scientific
computation,
machine
learning.
These
are
all
places
where
scale
performance,
reliability
really
matter,
and
it
for
us
can
couple
that
with
a
highly
productive
story.
I
think
we
could
do
great
things
right.
So
this
is
another
place
where
there
are
some
great
libraries
out
there.
C
You
know
there's
like
nd
array,
for
example,
but
they
need
more
sustained
attention
to
get
to
a
really
1.0
place
to
build
a
foundation
and
I
would
love
to
hear
from
all
of
you
again
after
the
talk
on
you
know
what
what
other
gaps
in
the
library
ecosystem
are
really
holding
you
back?
Ok,
so
that
is
sort
of
about
getting
libraries
to
actually
exist,
but
once
they're
out
there,
how
do
you
find
them
right?
So
you
know,
discoverability
superficially
seems
like
a
fairly
easy
problem.
C
Just
use
Google,
you
know
or
do
a
search
on
crates,
I/o
or
whatever,
but
it's
actually
really
subtle.
Right,
if
you
are
trying
to
use
rust
in
production-
and
you
need
a
library,
you
want
to
very
quickly
establish
that
you
know
this
libraries
gonna
meet
your
needs
that
it's
well
maintained,
that
it's
high-quality
and
so
on
and
so
forth.
That's
compatible
with
the
rest
of
the
ecosystem.
There
are
a
lot
of
attributes
that
you're
looking
for
beyond.
C
Just
does
this
library
exist,
and
so
then
we
start
getting
into
things
like
you
know,
curation
and
rating
and
so
on,
but
there's
a
tricky
balance
to
try
to
achieve
there
right,
because
we
want
to
highlight
the
best
libraries
and
draw
people
toward
them.
But
first
of
all
what
is
best
mean
right.
We
all
have
different
ideas
about
what
we're
looking
for
in
a
library,
and
we
have
to
calibrate
that
in
the
right
way,
so
we
incentivize
the
right
things
but
I
think
even
more.
Concerning
right.
C
Russ
ecosystem
is
very
young,
there's
a
lot
of
innovation
waiting
to
happen,
and
we
need
to
be
careful
not
to
sort
of
coalesce
around
a
particular
library
when
something
better
could
be
coming
down
the
pike.
But
now
that
we've
highlighted
this
one,
you
know
the
first
mover
advantage
has
locked
at
it
right.
So
somehow
we
got
to
navigate
this
balance
and
it's
gonna
be
a
tricky
thing.
I
think
one
source
of
inspiration
here
is
projects
like
ember
observer.
You
know
so
ember
is
a
JavaScript
framework.
C
It
has
a
big
community
around
it
and
faces
similar
discoverability
problems.
Ember
observer
tries
to
curate
the
ecosystem
and
a
pretty
sophisticated
way,
so
there's
sort
of
a
mixture
of
like
objective
criteria.
Lee
does
this
add-on
have
good
documentation?
Does
it
have
tests
so
on
and
so
forth,
and
then
there's
some
measure
of
actually
human
review
and
that
all
gets
put
into
a
score
that
then
you
know
highlights
add-ons
in
particular
areas
right.
So
maybe
something
like
this
could
work
for
us
and
we
won't
be
starting
from
square
zero
here.
C
There
are
already
some
good
curated
lists
of
libraries
in
Russ
that
we
can
draw
inspiration
from
as
well,
but
I
think
we
are
approaching
the
time
we're
actually
having
some
official
curation
and
search
tools.
Discoverability
tools
is
a
pretty
high
priority,
I'd
like
to
see
them
on
crits
I
out
personally,
okay,
so
that's
that's
discoverability.
C
So
documentation
is
a
really
important
example
right
if
the
library
is
not
documented,
it
might
as
well
not
exist
for
a
lot
of
people-
and
you
know
I
was
super
pleased
to
see
in
you
know
in
the
last
month,
a
new
site,
pop-up
Docs
RS,
which
totally
automates
the
documentation
system
right.
So
if
you
have
published
a
library
to
create,
say
yo
and
you
go
to
Docs
RS,
it
stocks
are
up
basically
without
you
having
to
do
any
work.
You.
C
Know
and
I
think
there's
a
lot
of
interesting
potential
there
for
actually
integrating
dots
across
libraries
so
that
the
ecosystem
feels
very
cooking
right
and
you
can
you
know
if
api's
are
being
shared
across
libraries,
you
can
browse
from
one
to
the
other
and
so
on
so
I
think.
That's
a
really
important
area
to
keep
focusing
on
Doc's
lesson
has
made
huge
strides
already.
Another
related
thing
for
quality
obviously
is
testing
and,
as
with
many
of
these,
things
like
rust
is
already
in
a
pretty
good
place,
but
we
can
aim
higher
right.
C
So
we
have
good
CI
tools.
We
have
Travis
integration
and
so
on,
but
you
do
have
to
know
how
to
set
it
up.
There's
some
work
to
get
that
going.
We
could
make
that
more
push-button.
Alright,
we've
done
that
in
a
lot
of
places.
Why
not
have
cargo
new
automatically
generate
travis
integration?
For
you,
something
like
that
right
and
then.
C
Similarly,
rust
comes
out
of
the
box
with
a
unit
testing
framework
and
that's
great,
but
we
could
really
open
the
door
to
more
custom
testing
and
benchmark
frameworks,
and
you
know
the
sky's
the
limit
in
terms
of
what
the
community
can
do
so
I
think
that's
another
really
important
area
to
focus
on
and
then
looking
more
of
the
code
itself.
I
think
there
are
many
important
questions
about
rust:
the
language
as
you're
developing
a
library,
particularly
if
you're
writing
unsafe
code.
You
know
what
can
you
assume
about
safe
code?
What
do
you
have
to
guarantee?
C
Will
future
versions
of
rust
and
break
your
unsafe
code
right?
These
are
some
tricky
questions,
so
we've
recently
formed
a
straight
team
to
start
laying
out
some
of
these
guidelines
and
actually
starting
to
specify
these
four
pieces
of
rust.
That's
gonna
be
a
long
haul.
This
is
really
hard
work,
but
I
think
it's
it's
vital
to
the
long-term
quality
of
the
ecosystem
right
and
we
should
look
for
other
kinds
of
things
like
this.
Like
restarting
the
API
conventions
system,
you
know,
so
we
have
good
documentation
on.
C
You
know
how
you
should
be
designing
your
api's
and
so
on.
These
are
all
things
we
can
do
that
to
increase
library
quality
across
the
board
cool
okay.
So
that
was
the
library
story.
Let's
look
at
one
more
team
and
a
little
bit
of
detail,
so
the
the
tools
team
right
has
encompasses
quite
a
range
of
things.
I'm
gonna
focus
on
just
a
few
here
and
I.
Think
tools
are
one
of
the
places
that
have
the
greatest
potential
to
improve
productivity
right.
C
Right
so
so,
probably
you
all
know,
Russ
up
is
a
way
to
get
rust
itself
to
upgrade
some
new
versions,
but
it's
so
much
more
than
that
right.
The
vision
is
rust
up
is
a
way
to
acquire
tool
chains
for
things
like
cross-compilation
right,
and
this
is
another
place
where
we
really
want
to
push
button
experience.
So
if
you
want
to
develop
on
a
linux
box,
make
an
android
app,
we
want
there
to
be
one
line.
You
write
to
rust
up
to
say:
I
want
Android
and
it'll
download
everything
necessary
on
your
system.
C
You
know
NDK
wise
to
actually
get
that
done
as
well
as
the
the
rusts
will
chain
itself.
So
we
have
some
pieces
of
that
today.
The
NDK
support
is
an
ongoing
thing.
Hopefully
we'll
have
some
news
there
in
the
next
couple
months
and
then
Brian
again
has
also
been
hard
at
work
on
getting
rusts
hooked
into
and
script
in
and
analyze
them.
C
Another
thing:
that's
really
important
for
productivity
is
not
having
endless
bike
sheds
about
code
formatting,
and
so
we
have
the
rust
format,
tool,
Thank
You
Nick
for
spearheading
that
effort.
But
of
course
we
have
yet
to
actually
reach
consensus
as
a
community
as
to
what
that
format
should
be
so
Nick
very
bravely
is
heading
up
the
bike
shed
of
bike
sheds.
So
we
have.
We
now
have
a
rust
format,
strike
team,
which
I
think
had
their
inaugural
meeting
earlier
this
week
and
the
plan
is
to
actually
layout
rust
format
conventions.
C
That's
not
the
defaults
for
the
tool
that
the
whole
community
can
use,
and
so
we
can
just
not
think
about
this
ever
again.
Okay
and
then
last
of
these
poor
tools
is
cargo,
which
of
course,
everybody
loves
cargo
cargos,
a
great
draw
for
rust,
but
there's
more,
we
can
do
so.
You
know
one
of
the
pain
points
in
the
ecosystem
is
to
do
with
the
way
that
semver
is
managed
and
the
way
that
dependencies
of
a
package
may
or
may
not
be
duplicated
under
under
various
circumstances.
C
Another
really
important
area
of
focus,
as
we've
started,
to
talk
to
really
large
shops
that
want
to
use
rust
one
of
the
holdups
is
they
tend
to
have
really
large
build
systems
with
really
large
opinions
and
cargo
has
its
own
opinions,
and
it's
not
clear
how
to
integrate
this.
So
you
know
again,
we
have
some
initial
ideas
about
what
this
might
look
like.
If
this
is
a
problem
for
you
talk
to
Alex
and
let's
get
to
the
bottom
of
it,
okay,
but
of
course
IDs
are
the
big
topic
for
tools,
especially
given
the
survey
results.
C
C
So
racer
is
not
an
IDE,
but
it's
sort
of
part
of
a
package
that
could
go
into
an
IDE
and
it
aims
to
provide
things
like
autocomplete
and
go
to
definition
really
really
quickly,
and
it
does
this
in
a
prettier
istic
way.
So
it's
not
actually
using
the
compiler
at
all,
because
the
compiler
is
quite
there
yet
speed,
wise
and
racers
come
along.
You
know
quite
a
long
way,
so
they're
already
like
some
good
tools
in
that
direction,
along
a
very
different
axis.
We
have
the
IntelliJ
russ
plugin,
which
is
also
rapidly
maturing.
C
Intellij,
uses
a
whole
different
approach.
They
have
a
very
intense
sort
of
framework
for
writing,
IDs,
which
is
basically
building
a
whole
compiler
themselves.
So
they
have
started
this
process
for
rust
and
things
are
coming
along
quickly,
but
I
think
you
know
one
of
the
things
we're
excited
about
in
this
space
is
to
try
a
somewhat
different,
Avenue
right.
C
You
know
questions
like
go
to
definition
or
find
all
references,
and
so
on
so
Nick
and
Jonathan,
who
are
going
to
be
demoing
in
just
a
second,
have
been
hard
at
work
in
this
space
and
the
vision
is
we
have
an
IDE?
Maybe
it's
V
s
code,
maybe
it's
add-on.
Maybe
it's
something
else.
It's
talking
to
a
central
service
called
the
Russ
language
service,
which
is
then
in
turn
talking
to
some
variety
of
sources
of
answers
about
your
code.
C
B
Yeah,
okay
cool,
so
as
Aaron
was
saying,
we
had
this
idea
a
couple
weeks
ago.
What
if
we
took
like
a
best
of
both
worlds
approach,
we
use
racer
20
more
on
something,
that's
more
interactive
and
then
we
can
use
the
compiler
the
compilers
metadata
directly
when
he
wants
something.
That's
a
little
bit
more
deep,
like
precise
knowledge
about
your
project,
so
we
wrapped
it
together
into
the
prototype
very
early
proof
of
concept.
Prototype
idea
of
this
rust
LS.
B
So
the
the
RLS
allows
us
to
do
the
same
kind
of
things
that
you
already
are
used
to
doing
in
racer.
So,
for
example,
we
can
do
the
same
autocompletes
that
we
did
before
gives
us
a
list.
We
can
scroll
around
and
pick
a.
You
know,
a
method
that
we
want
to
call,
and
you
saw
as
we
were,
selecting
that
that
we
had
type
information
sitting
there
that
razor
had
already
kind
of
parsed
and
figured
out.
But
what
can
we
do
if
we
have,
like?
You
know,
precise
type
information?
B
So
if
we
have
precise
type
information,
for
example,
we
can
hover
over
things
and
see
the
types
if
there
is
rust.
Docs
we
can
see
the
documentation,
and
so
this
is
starting
to
feel
like.
Oh,
this
is
starting
to
feel
like
a
little
bit
more
like
an
IDE.
You
can
see
the
the
squiggle
here,
for
example,
so
we
have
errors.
You
know
we're
using
the
compiler
behind
the
scenes.
If
we
hover,
we
can
see
the
error.
B
We
can
see
a
little
bit
more
about
what
going
on
and,
of
course,
since
it's
straight
from
the
compiler,
it's
exactly
the
same
error
as
the
compiler
would
give
you.
So
we
can
do
you
know
types
on
hover.
We
can
do
error
messages.
The
next
thing
that
we
need
to
be
able
to
do
is
to
do
navigation
through
your
code.
So
we
can
do
two
like
a
go-to
symbol,
so
just
type
the
name
of
a
symbol,
and
then,
when
we
do,
we
can
jump
straight
to
its
definition,
so
you've
seen
some
tools
already
out
there.
B
That
can
do
this
kind
of
thing,
but
with
the
precise
type
of
information
we
can
just
go
straight
to
the
definition.
We
can
find
all
the
references
for
a
given
symbol,
for
example,
and
here
you
see,
you
know
like
the
full
list
of
where
that
symbol
is
being
used.
And
again
this
isn't
like
searching
to
your
code
like
grep.
This
is
the
precise
information,
and
if
we
have
the
precise
information,
we
can
kind
of
go
that
next
step
that
your
user
ID
is
going.
We
can
actually
use
that
to
do
a
refactor,
so
we
can.
D
B
I
know
it's
gonna,
forget
that
one!
It's
like
remember,
macros,
remember,
Mac
OS,
all
right,
so
we
can
do
final
references
and
if
we
can
do
final
references
again,
we
can
do
this
refactoring
to
be
able
to
rename
that
symbol
and
precisely
rename
it
rather
than
doing
search
replace
because
we
know
all
the
references
we
can
do.
A
safe
rename,
refactor.
B
So
we're
really
excited
about
what
this
can
grow
into
again.
Like
I
said
this
very
early
proof
of
concept,
lots
and
lots
of
duct
tape,
but
we
want
to
tear
that
duct
tape
down
and
build
it
back
up
to
being
the
real
RLS.
We
kind
of
showed
it
working
in
vs
code.
But
of
course
we
built
it
in
such
a
way
that
you
can
plug
this
into
any
IDE
in
the
editor
and
if
you
want
to
help
us
move
it
on
to
the
your
favorite
IDE.
A
The
last
thing,
I
had
to
say
is
basically
that
we
have
also
a
lot
of
efforts
from
other
teams,
so
the
docs
team,
for
example,
is
embarking
on
a
new
book
based
on
what
we've
learned
about
how
people
learn
rust,
trying
to
take
a
different
approach
that
should
be
more
effective
and
improve
on
the
one
we
have,
which
is
already
quite
good.
We're
also
we're
also
working
on
looking
at
different
ways
to
improve
the
ecosystem.