►
From YouTube: Core Team Keynote — Aaron Turon & Niko Matsakis
Description
Aaron and Niko will deliver an update on the state of all things Rust. You don't want to miss it!
http://www.rust-belt-rust.com/
A
Just
wanted
to
say
this
has
been
a
pretty
exciting
year
for
us,
so
I'm
gonna
talk
a
little
bit
about
some
of
the
technical
stuff,
but
you
know
just
looking
alone
at
the
set
of
conferences,
so
we
had.
Last
year
we
had
Russ
camp
this
year.
We
had
rust
comp
rust
fast
in
Berlin,
and
now
we
have
Russ
Bell
dress,
so
I'm
pretty
excited
about
that
and
I
want
to.
Thank
you
guys
for
coming
and
thanks
to
all
the
organizers
and
the
sponsors
for
making
this
happen.
So
I'm
just
gonna.
Do
this
myself.
A
This
is,
and
also
a
much
bigger
crate,
I/o
ecosystem
and
so
forth,
and
so
you
can
do
a
lot
more
with
stable
rest
now
than
you
could
then,
and
we've
also
had
a
lot
of
exciting
language
features
that
are
been
implemented
and
worked
out
and
special
aspect
and
are
now
coming
kind
of
starting
to
become
available
and
stable
right
about
now.
So
specialization
and
infiltrate
are
available
on
nightly.
A
The
question
mark
operator
was
just
specialized,
I
think
it'll
be
in
the
next
release,
if
not
the
one
after
that
and
we're
gonna
soon
have
custom
derives
that
you
can
do
things
like
derive,
use,
Saturday,
unstable
and
so
forth,
which
has
been
a
really
popular
big
feature
request.
We've
also
done
a
lot
of
work,
re
architecting,
the
compiler,
laying
the
groundwork
for
some
of
the
stuff
that
we're
going
to
talk
about
now
for
2017.
A
So
we've
done
a
completely
new
IR,
which
was
a
big
effort
and
especially
have
a
big
community
effort
which
is
really
exciting,
and
that
allowed
us
to
do
some
long-standing
optimizations
to
our
code
generation.
Incremental
compilation
is
starting
to
work,
hopefully
in
the
next
few
months,
we'll
have
it
really
in
use
for
the
first.
For
the
first
time,
and
also
we
have
a
brand
new
error
message,
output,
which
I
think
many
of
you
have
experienced.
A
That
makes
there
is
much
easier
to
follow
and
so
forth
and,
finally,
we're
now
working
much
more
stable
e
on
much
more
platforms
right.
So
a
Windows
support
is
much
better.
You
can
target
Musil,
which
lets
you
deploy
your
binaries
to
any
Linux
ever
or
whatever,
something
like
that,
and
then
you
have
rust
up
to
easily
switch
between
them.
So
that's
really
cool,
but,
moreover,
we've
done
all
these
things
without
totally
messing
up
rust.
It
turns
out
people
still
really
like
it.
A
We
hope
to
keep
that
up,
so
we're
pretty
proud
of
the
fact
that
you
know
we
came
in
top
on
this
survey
with
79
percent
of
people
who
use
Russ
still
want
to
use
rust
and
that's
basically
the
kind
of
numbers
we
like
to
see.
But
not
only
do
we
have
people
who
are
surveyed,
but
we've
also
had
a
lot
of
adoption
coming
out
of
industry
as
well.
A
B
Nico
yeah
and
I,
just
I,
want
to
say
in
terms
of
other
things
that
we've
managed
to
not
mess
up.
I.
Think
one
of
the
most
exciting
aspects
is
the
rust
community.
So
we
heard
with
the
opening
yesterday
about
the
importance
of
being
welcoming
and
I
think,
as
the
community
has
grown
I've
been
extremely
encouraged
to
see
that
it's
keeping
all
of
these
values,
central,
which
is
pretty
amazing,
so
keep
up
the
good
work.
B
Okay,
but
now
time
for
some
prognostication,
so
everybody's
eager
to
hear
you
know
what
are
our
plans
for
the
next
year
and
one
of
the
nice
things
about
doing
development
in
the
open,
as
we
do
with
rust,
is
that
we
get
to
talk
about
this
all
as
a
community
and
actually
chart
out
a
course
together.
So
we
don't
in
fact
need
a
crystal
ball
to
figure
out
where
rust
is
headed,
we're
gonna
do
it
together.
B
So,
in
terms
of
you
know,
discovering
problems,
we
have
a
few
different
ways
of
gathering
that
data,
so
we
sent
out
a
survey
which
I'll
talk
about
a
bit
later.
We've
also,
the
community
team
has
been
reaching
out
to
companies
that
are
using
rest
or
want
to
use
rust
to
figure
out
where
their
problems
are,
where
they'd
like
to
see
rust
grow.
And,
of
course
we
just
have.
You
know
conversations
amongst
ourselves
as
as
a
community
as
we're
doing
outreach
and
so
on.
So
once
we've
got
these
problems
laid
out
that
we
want
to
solve.
B
Then
we
need
to
execute,
and
so
the
idea
is
gonna
be
that
every
six
weeks,
which
is
synchronised
with
our
release
cycle,
the
various
rust
teams
will
sort
of
do
a
sprint.
So
they
lay
out
in
this
six
weeks.
What
are
we
going
to
do
to
move
the
ball
forward
on
these
yearly
goals
that
we've
laid
out
right,
and
this
is
really
exciting,
because
I
think
I've
heard
from
a
lot
of
people.
You
know
there's
so
much
going
on
in
rust.
B
It's
really
hard
to
tell
you
know
to
sort
of
keep
on
top
of
it
and
it
held
what
are
the
most
important
stuff
right.
So
these
yearly
goals
are
the
most
important
things
we're
targeting,
but
then
these
six
week
Sprint's
give
you
a
sense,
for
you
know
if
I
want
to
get
involved
as
I
volunteer,
where
do
I
go?
How
can
I
actually
help
out
with
these
efforts?
So
all
of
that
will
be
surface
probably
and
github
some
easy
to
find
way
and
that'll
be
starting
in
2017
and
then
fine.
B
The
final
piece
of
this,
which
I
think
is
really
important,
is
we
want
to
tell
this
story
to
the
broader
world
right?
So
you
know
if
we
as
a
community
have
a
hard
time
following
everything,
that's
happening
in
rust,
and
the
people
outside
of
this
community
have
an
even
harder
time.
What's
you
know
following
the
story
of
rust,
so
the
idea
here
is
at
the
end
of
the
year
and
when
we
finished
this
process
we
put
together
a
big
retrospective
that
says
as
a
community.
You
know
what
did
we
do?
B
What
was
the
story
of
rust
this
year?
How
did
it
evolve?
What
is
the
state
of
our
ecosystem?
How
do
you
dive
into
rust,
and
so
you
know
on
yearly
increments,
the
world
gets
to
hear
about
rusts
evolution
in
a
very
clear
way,
so
I'm
really
excited
about
this
process
and
we've
already
started
taking
a
number
of
steps
toward
it.
Okay,
so
with
that
overview,
let
me
dive
into
a
little
bit
more
of
the
specifics.
B
So
I
mentioned,
you
know
that
we
sent
out
a
survey
and
got
actually
tremendous
response
to
it
more
than
I.
Think
any
of
us
anticipated.
So
we
had
over
3,000
respondents
to
the
survey
and
the
survey
was
targeted
at
both
people
who
currently
use
rust
have
used
rust
in
the
past,
but
are
no
longer
using
it
or
people
who've
never
used
rust
right.
B
We
were
interested
to
hear
from
all
of
those
different
camps,
so
the
chart
at
the
bottom
you
know
shows
basically
people
the
breakdown
and
people
actively
using
rust
versus
not
so
about
a
third
of
the
respondents
are
not
using
rust,
which
is
great.
That's
that
gives
us
a
lot
of
insight
into
what
it's
gonna
take
to
grow,
rusts
adoption.
You
know
what
are
the
blockers
to
people
actually
picking
it
up?
Okay,
so
what?
What
did
we
hear
out
of
this
survey?
So
we
got
a
number
of
challenges
by
far
the
clearest
cut.
B
One
is
that
rust
has
a
steep
learning
curve.
I,
don't
think
this
comes
as
a
surprise
to
anybody
in
this
room.
That's
definitely,
you
know
part
of
the
the
meme
around
rust
right
now
and
the
feeling
generally,
is
it's
worth
it
right.
You
get
through
those
couple
of
weeks
fighting
the
borrow
checker
it's
hard,
but
then
once
you're
over
that
hump,
it's
worth
it
right,
but
how
many
people
do
we
end
up
losing
in
those
first
couple
of
weeks
right?
Can
we
fix
this
okay
so
that
one
in
four
respondents
talked
about
the
learning
curve?
B
Again?
Unsurprisingly,
given
how
early
we
are
in
the
language
development,
a
lot
of
people
are
talking
about.
Rust
doesn't
have
enough
libraries,
it's
not
covering
my
needs
right,
so
this
is
this
is
expected,
but
it's
good
to
see
it
sort
of
quantitatively
showing
up
in
the
survey
and
then
on
a
similar
note.
B
A
lot
of
people
talked
about
just
the
general
maturity
of
the
language,
the
tooling
and
so
on,
wanting
rust
to
be
more
mature
before
they
felt
comfortable,
trying
to
use
it
in
production,
for
example,
okay,
next
one
came
as
I
think
a
surprise
to
many
of
the
core
developers
since
we're
all
Emacs
users,
at
least
the
proper
ones,
but
it
turns
out
a
lot
of
people
love
II's.
A
lot
of
people
depend
on
IDs
for
their
core
workflow,
a
lot
of
companies,
basically
across
the
board,
use
IDs
and
so
for
many
people.
B
It's
just
a
total
non-starter
to
say
pick
up
this
language
that
doesn't
have
a
good
IDE
experience
and
so
they're.
You
know
that
was
mentioned
in
one
in
nineteen
respondents
overall,
but
I
think,
most
importantly,
if
you
look
at
that,
you
know
third
chunk
of
people
who
aren't
actually
using
Rusted
a
one-in-four
cited
ITES
as
an
important
reason
right.
So
this
is
this
is
a
huge
challenge
and
then
everybody
knows
the
compiler
could
be
a
little
faster,
and
this
is
especially
important
as
you
do
try
to
use
rest
in
production.
B
It's
the
number
one
complaint
we
hear
from
all
of
our
production
users,
so
I,
don't
think
any
of
these
challenges
come
as
a
great
surprise,
but
I
think
there
are
some
interesting
themes
here
right.
So,
if
you
you
know
or
like
Nikko
or
me,
you're,
you
know
sort
of
bred
to
do
language.
Design
right
would
come
from
this
academic
background
and
so
we're
eager
to
like
build
more
language
features
and
make
the
language
richer
and
so
on.
It's
very
tempting
to
focus
on
that
stuff.
B
But
really
none
of
these
challenges
are
about
making
the
language
nicer.
You
know
from
like
academic
design
perspective.
What
they're
really
all
about
is
productivity.
People
want
to
people,
see
the
potential
value
in
rust,
but
they're
worried
about
being
productive,
they're
worried
about
learning
it
quickly,
they're
wearing
worried
about.
You
know,
mature
libraries
that
have
their
backdoor
IDs.
That
may
make
them
productive
right.
So
there
are
a
lot
of
different
ways
to
think
about
productivity
right.
B
So
here,
I
just
have
a
few
different
questions
that
are
related
to
productivity,
and
you
know
I
don't
want
to
say
that
rust
is
completely
unproductive.
I
mean
some
of
these
things.
We
actually
do
really
well
right.
So
if
you
want
to
write
correct
code,
rust
is
a
very
productive
way
to
do
that
compared
to
a
lot
of
other
languages
right
because
it,
the
compiler,
has
your
back
across.
You
know
so
many
different
issues.
The
standard
library
is
built
very
carefully
to
guide
you
to
the
the
right
kinds
of
patterns
right.
B
Similarly,
if
you
want
to
write
code,
that's
fast
rust
is
a
much
more
productive
way
to
do
that
than
many
other
languages.
Okay.
So
so
we
get
some
of
that
right,
but
then
some
of
these
other
questions
don't
really
sound
like
rust
today,
right
how
quickly
can
I
start
writing
real
code?
Well,
there's
that
learning
curve
with
the
borrow
checker
that
we
all
sort
of
are
familiar
with.
If
you're
you
know
at
a
company
that
wants
to
start
spinning
up
use
of
rust,
how
long
is
it
gonna?
Take
you
to
train
up
a
team
right?
B
Can
you
use
rust
to
prototype?
Does
that
make
sense
all
right,
so
I
think
these
are
really
important.
Questions
for
driving,
rust,
adoption
and
I
think
it's
tempting
to
imagine
that
rust
is
just
inherently
going
to
be
bad
at
these
things
compared
to
some
of
the
others
right,
because
rust
has
this
emphasis
on
safety
on
reliability
on
performance,
and
so
it's
easy
to
think
that,
well,
those
things
fundamentally
come
at
a
cost
right
that
it's
gonna
be
harder.
It's
going
to
be
slower
right,
so
you
might
think
that
this
is.
B
This
is
just
an
inherent
trade-off,
but
I
want
to
tell
you
something
about
trade-offs.
Alright,
so
here's
a
slide
from
last
year's
rust
camp
where
we
tried
to
really
articulate
what
rust
1.0
represented.
What
were
the
some
of
the
core
ideas
behind
rusts
and
the
theme
here
each
and
every
one
of
these
lines
is
talking
about
what
seems
to
be
a
fundamental
trade-off
that
rust
overcomes
right.
So
you
might
think
that
if
you
want
safety
in
a
language
you
have
to
have
a
garbage,
collector
Russ
says
no.
Actually
you
can
have
both.
B
At
the
same
time.
You
might
think
that
if
you
want
to
do
concurrent
programming,
you're
gonna
have
to
cope
with
databases
and
Russ
says
no.
Actually,
we
can
do
both
at
the
same
time
right,
and
so
the
overall
message
is
that,
as
a
community,
we're
actually
really
good
at
rethinking
these
trade-offs
at
overcoming
them.
We
know
how
to
have
our
cake
and
eat
it
too,
and
so
I
think
the
challenge
of
this
year
for
rust
is
to
start
thinking
about
productivity
as
a
core
value
of
rust.
B
That's
on
the
same
level
as
speed
and
reliability
right,
so
I
want
personally,
at
the
end
of
2017,
to
be
able
to
claim
this
as
a
slogan
that
really
applies
to
rusts
and
I.
Think
we're
well
positioned
to
start
overcoming
some
of
these
trade-offs.
So
with
that
said,
the
rest
of
this
talk.
What
we're
gonna
do
is
look
at
each
of
the
areas
of
development
in
rust,
each
of
this
sort
of
teams
within
rust
and
think
about
how
those
teams
can
can
contribute
basically
to
the
push
toward
productivity,
the
rest,
starting
with
the
language.
A
We
can
look
at
it
different
places
we
can
tweak
and
if
we
look,
what
does
rust
do
really
well
today,
there
is
a
lot
that
we
do
great
right
and
I
think
you
can
say
what
do
people
really
like
using
about
rust
in
terms
of
what
I
like
using
about
rust?
Is
this
sort
of
feeling
I
get
that
like
galactic
power
right
I
can
just
throw
out
a
few
lines
and
I'm
like
a
magician
and
I,
just
kind
of
say
what
I
want
and
I
get?
A
Not
only
is
the
code
kind
of
pretty
and
does
what
I
wanted
to
say
pretty
concise,
but
it
also
actually
executes
really
fast
I.
Don't
have
to
go
rewrite
it
later
to
do
it
the
fast
way
or
something
like
that
right,
so
I
can
write
an
iterator
that
finds
the
longest
line
and
and
it
works
I
can
make
that
iterator
run
in
parallel,
using
round
which
I'll
talk
about
later
or
you
know,
using
some
of
this
upcoming
futures
and
Tokyo
work.
A
I
could
send
RPC
requests
to
servers
and
get
responses
and
have
all
of
that
be
handled
both
simply
but
also
efficiently.
All
right,
and
if
we
look
at
this
chart,
you
can
kind
of
see
what
I
mean
by
efficiently.
This
comes
from
I
think
it
was
Aaron's
blog
post
right
there
named
Alex's
blog
post
a
while
back
measuring
the
performance
of
hello
world
requests
on
the
server
so
kind
of
a
baseline
performance.
A
How
many
requests
can
you
process
per
second,
and
we
see
that
rust
comes
in
here
right,
the
biggest
bar,
but
if
you
think
back
to
before,
there
was
rust-
and
you
were
to
say,
here's
a
chart
of
different
servers
and
I
can
tell
you
that
one
of
them
is
implemented
in
the
language
with
the
strongest
safety
guarantees
using
abstractions.
All
the
way
down
to
the
as
far
down
as
we
could
get
them
kind
of
in
the
most
idiomatic
style.
You
probably
wouldn't
have
guessed.
Oh,
it
must
be
the
fastest
one.
You
would
have
thought.
A
Oh,
that's
the
one
down
there.
That's
the
slow
one,
but
it's
not
the
case
right.
We
turned
that
that
trade
off
and
just
kind
of
made
it
go
away
and
I
think
that
that
emphasis
on
things
being
reliable
and
fast,
you
can
see
it
even
in
small
fragments
of
Rusco
and
its
really
nice.
So
here's
a
little
bit
of
Russ
code,
a
kind
of
simplistic
one.
It
takes
a
name
and
prints
it
out.
A
It
says
it
greets
the
user
by
name
right,
but
even
here
you
see
that
okay,
maybe
the
user
has
declined
to
provide
a
name
or
we
don't
have
one
so
to
represent
that
we
use
an
option
type
instead
of
like
a
null
pointer,
and
that
means
that
when
we
match
on
it,
we
have
to
remember
to
handle
this
case.
That's
nice.
So
now
we
will
not
just
throw
an
exception
or
something
right,
and
we
also
have
up
here.
A
We
see
that
this
is
actually
a
reference
to
an
option
which
is
part
of
the
ownership
and
borrowing
system
that
lets
us
have
data
race,
freedom
and
lets
us
have
not
need
to
give
the
garbage
collector
to
get
safety.
So
this
is
really
cool
and
I
could
submit
this
code
to
the
compiler
and
run
it.
But
I'm
gonna
have
a
slight
problem.
Alright,
there's
this
is
error
and
it's
a
little
bit
irritating.
A
But
it's
it's!
Okay,
we're
experienced
rest
users,
mismatched
types,
I
know
what
to
do.
The
problem
is
right
here:
I
was
matching
on
a
name
and
treating
it
like
it's
an
option,
but
it's
actually
a
reference
to
an
option.
So
I
need
a
star
so
that
I
can
match
on
what
the
reference
refers
to
right.
No
problem,
I'm,
gonna,
compile
it
now
and
now
it's
gonna
work.
A
A
This
is
like
possibly
enough
to
say:
I
can't
even
print
a
string
on
the
screen
with
this
language.
That's
it
I'm
gonna,
go
cohdon,
something
else
right
and
that's
kind
of
what
we'd
like
to
change.
But
the
interesting
thing
about
this
is
that
if
we
can
improve
this
and
do
it
in
the
right
way,
it's
gonna
benefit
everyone
right,
because
even
the
experienced
users
also
encountered
this
we've
just
kind
of
learned
to
move
past
it.
A
There
are
a
bunch
of
examples
that
kind
of
fit
in
this
mold
right.
One
that
comes
up
a
lot
is
handling
how
we
handle
string
literals,
which
is
a
very
kind
of
accurate
way
to
model
how
they
work.
But
in
particular
there
are
two
string
types
right:
a
string
literal
is
statically
allocated
in
the
binary,
so
it
has
a
different
type
because
it
doesn't
need
to
be
freed.
It's
an
ampersand
store
versus
capital
string.
A
That
represents
a
heap-allocated
string
buffer,
but
the
problem,
the
end
effect
is
when
I
write
a
little
hollow
world
program
like
this.
You
know
I
get
this
error
right
away
and
it
has
a
lot
of
kind
of
confusing
components
to
it
and
it
might
be
enough
to
turn
people
off
and
I
know
that
when
I
do
tutorials,
this
is
literally
the
first
thing.
I
do
right.
A
I
said:
let's
talk
about
hello
world
so
that
we
can
all
get
past
the
string
thing
and
go
on
and
that's
a
little
unfortunate
and
there's
another
example
that
comes
up
a
lot
which
has
to
do
with
the
borrowing
system.
All
right
so
here
I
have
a
mutable
reference
to
a
map
and
I'm
looking
up
a
key
in
it
and
I'm
doing
something
with
this
key
and
so
long
as
I'm
in
this
branch,
where
I
found
it
the
the
value
in
the
map,
I
have
a
reference
in
to
the
map.
A
The
compiler
is
gonna
prevent
me
from
trying
to
mutate
the
map
like
insert
new
keys
and
that's
a
good
thing,
because
if
I
did
that
I'd
probably
crash
my
program
and
that
kind
of
makes
sense
it's
borrowed
when
it's
borrowed
I
can't
mutate.
It.
However,
on
this
other
branch,
where
there
was
nothing
in
the
map,
I
also
can't
mutate.
The
map
right
and
you
get
an
error
like
this
one
and
the
problem
here
is
not
that
there's
a
fundamental
thing:
it's
that
the
compiler
is
kind
of
over.
Approximating
it's
not
smart
enough
to
realize.
A
Oh
on
this
branch,
there
actually
isn't
any
the
map
isn't
really
borrowed.
Now.
This
is
sort
of
interesting,
because
this
constraint
led
us
to
some
really
cool
API
is
like
entry,
so
I'm
sort
of
happy.
It
was
there
but
I
think
it's
time
for
it
to
go,
and
a
lot
of
the
refactoring
that
we've
done
will
make
that
possible.
C
A
These
little
things
that
kind
of
add
up
right
and
there's
a
list.
This
is
some
things
I've
heard
about
like
about
other
things
and
in
all
of
these
cases,
I
want
to
emphasize
it's
not
that
we
just
sort
of
didn't,
think
about
it
or
we
made
it
harder
on
purpose
or
I,
don't
know
what,
but
there's
a
real
technical
trade-offs
involved
right
and
it
seems
like
there's
like
this
tug-of-war
between.
A
Can
we
get
precision
and
explicitness
so
that
you
don't
make
mistakes
or
can
we
make
it
easy,
but
then
maybe
it's
gonna
be
slow,
and
so
what
we
need
to
do
when
we
think
about
these
is
not
just
say.
Oh
that's
paper
over
it
with
some
have
a
compiler
or
insert
a
bunch
of
coercion,
x'
that
are
gonna,
allocate
memory
everywhere
and
kind
of
turn
it
into
lose.
Some
of
the
great
things
about
rust.
We
need
to
find
ways
to
preserve
those
things
and
solve
these
dilemmas
right
figure
out.
A
Where
is
it
most
important
to
keep
the
explicitness
and
where
can
we
let
it
go?
And
then
we'll
have
like
this
happy
dog
running
down
this
beach?
And
so,
if
we
look,
there
are
a
bunch
of
examples
where
we've
done
this
successfully.
I
think
in
the
language
and
one
of
my
favorites
is
the
closure
designer
and
that's
partly
because
it
was
the
first
thing.
I
worked
on
and
rust
five
years
ago
and
I'm
still
working
on
it
or
was
until
about
a
year
ago,
and
now
that's
a
nice
feeling.
It
worked
out
pretty
well
right.
A
A
Because
closures
have
to
accommodate
all
these
use
cases,
they
have
to
work
for
sequential
iterators,
parallel
iterators,
which
have
different
constraints,
because
you
have
to
prevent
data
races,
also
work
for
futures,
which
are
again
a
different
thing,
because
you're
kind
of
rolling
up
your
stack
frames
and
moving
things
into
the
heap
and
accommodating
all
of
this
with
one
abstraction
took
us
a
while
and
I
think
we
did
a
really
good
job
because
using
it
feels
very
natural.
You
sort
of
aren't
aware
of
all
the
complexities
necessarily
when
you
just
use
these
api's.
A
So,
for
example,
here
when
I
use
a
variable
in
a
closure
that
comes
from
my
surrounding
environment,
the
compiler
actually
has
to
decide
am
I
gonna.
Is
that
going
to
be
a
borrow,
a
mutable
borrow,
or
is
it
taking
ownership
of
this
variable
and
the
way
it
does?
That
is
by
looking
at
how
the
variables
used
right?
So
we
can
see
well,
if
you're
going
to
call
right
string
right
string
is
going
to
need
ownership
of
myself
it.
A
That
implies,
then,
that
the
closure
must
own
my
socket
so
that
it
can
kind
of
thread
the
ownership
through
and
that
that
just
winds
up
feeling
very
natural,
you
didn't
have
to
write
any
annotations,
but
you
haven't
actually
removed
explicitness
from
the
program
right.
You
just
didn't
have
to
repeat
yourself.
Essentially,
the
information
was
already
there
and
I
think
we
can
apply
similar
principles
to
a
lot
of
these
examples
right.
So
in
terms
of
this
match
example,
you
could
imagine
that
we
automatically
skip
past
references
because
there's
really
nothing
else.
A
You
can
do,
but
do
you
reference
them
when
you
match
on
them
and
then,
if
we
encounter
this
this
variable
and
we
can
see
how
is
it
used
and
make
the
decision,
then?
Is
it
going
to
be
a
reference
or
not
so
here
we
would
just
be
printing
it,
so
we
don't
need
ownership.
Similarly,
we
can
make
the
capital
string
type
potentially
able
to
handle
and
understand.
A
I
guess
also
the
reality
of
it,
and
so
that's
my
my
kind
of
overarching
goal
here
is
not
necessarily
any
one
of
these
changes,
but
the
idea
that,
when
we
think
about
language
changes,
let's
not
only
think
about
how
we
can
extend
the
language
to
do
new
things,
but
how
we
can
do
all
the
things
we
do
now
better
and
easier
and
more
productively.
Fine
well.
B
Thanks,
Nico,
okay,
so
what
about
libraries?
What
does
it
mean
for
Russ
libraries
to
be
productive,
so
I
think
taking
a
very
broad
view.
It's
pretty
simple
right.
We
need
libraries
for
sort
of
common
tasks
that
come
up
a
lot
to
exist,
that's
being
out
there
somewhere,
they
should
be
findable
right.
You
should
be
able
to
search
for
them
and
easily
find
your
way
through
crates,
I/o
or
some
other
way,
and
those
libraries
should
be
of
high
quality
right
if
you're
gonna
be
productive.
B
B
So,
first
of
all,
let's
talk
about
actually
building
libraries
right,
so
I
think
people
generally
know
that
rust
standard
library
has
taken
minimalistic
approach
for
a
lot
of
reasons
right.
So
it's
not
really
a
batteries
included
style
of
a
standard
library
and
that's
okay,
because
we
have
great
tooling,
with
cargo
and
crates
I/o.
So
it's
very
easy
to
pull
in
lots
of
external
libraries,
but
those
batteries,
even
if
they're
not
included
in
the
standard
library,
they
do
need
to
exist
somewhere
all
right.
B
B
So
here
are
just
a
few
ideas.
I
think
for
some
of
the
most
obvious
targets
for
this
year,
so
rust
on
the
server
has
sort
of
already
come
up
with
with
Tokyo
and
futures
that
work
is
well
underway.
I
think
that's
gonna
be
really
important
for
production
uses
of
rust,
but
there's
more
work.
We
can
do
on
rust,
concurrency
story
really
bringing
it
to
fruition,
as
well
as
a
number
of
other
areas.
B
B
So
one
thing
we've
been
taking
as
some
potential
inspiration
here
is
the
ember
ecosystem.
So
there's
a
site
called
ember
observer
that
has
very
carefully
set
up
a
bunch
of
metrics
some
objective
things
like
you
know,
downloads
or
github
stars
and
then
some
more
subjective
things
like
actual
curated
reviews
of
libraries,
so
I
think
we
could
do
something
similar
to
this
within
Craig's
I/o.
B
Similarly,
there's
actually
been
work
in
the
rust
ecosystem
to
categorize
libraries
into
different
domains
and
I.
Think
we
could
put
that
together
with
a
ranking
system,
to
make
it
much
easier
to
find
libraries
for
a
given
task.
What
about
quality
so
I
think
there
are
some
steps
we
can
take
to
improve
quality
across
the
board.
You
may
have
seen
the
docs
RS
website
that
already
came
out,
which
automatically
provides
documentation
in
a
central
place
for
everything
on
crates
I/o.
This
has
been
amazing
for
the
ecosystem,
but
there's
more
work.
B
We
can
do
to
improve
the
documentation
experience.
Another
thing
we
can
do
is
make
it
easier
for
projects
to
set
up
CI,
for
example,
as
part
of
cargo
new
or
provide
more
elaborate
testing
framework.
So
right
now
we
have
some
built
in
testing
and
benchmarking
in
the
rest
in
cargo,
but
it's
unstable
and
you
can't
actually
build
out
new
testing
frameworks,
so
we'd
like
to
improve
that
as
well
and
then
finally,
we're
we're
looking
at
some
sort
of
efforts
to
figure
out
how
best
to
write
unsafe
code,
which
is
really
crucial
for
these
lower
level.
B
Libraries
that
are
sort
of
the
foundations
of
the
ecosystem,
so
giving
guidelines
to
libraries
offers
us
to
how
to
do.
This
is
gonna,
be
hugely
important,
all
right,
so
sort
of
being
aware
of
time
I'm
going
to
skip
ahead
a
little
bit
quicker
here
so
that
that
was
sort
of
the
library
story.
I
think
there's
it's
a
big
space!
There's
a
lot
we
can
do
but
tooling,
is
also
extremely
important
and
I
think
there's
a
lot
to
say
about
the
tooling
story,
but
for
today
we're
gonna
focus
on
that
most
important
bullet.
B
We
saw
from
from
the
challenges,
which
is
the
IDE
experience.
So
rust
has
made
some
progress
on
this
front
over
the
last
year.
I'm,
probably
a
lot
of
you
are
familiar
with,
or
reviews
racer,
which
is
you
know,
a
tool
that
can
do
things
like
autocomplete
and
a
number
of
editors.
Racer
is
really
cool,
it's
very
fast,
but
it
works
totally
independently
of
the
compiler
right.
So
this
is
based
on
heuristics
and
its
own.
You
know
means
of
parsing
out
the
programs
that
you're,
writing
and
but
yeah,
but
it
covers
autocomplete.
B
It
coexists
with
lots
of
existing
editors
like
Emax
and
Emin,
and
so
on.
There's
also
a
rapidly
maturing
plugin
for
IntelliJ,
which
takes
a
similar
approach.
So
IntelliJ
in
general
has
a
very
rich
toolkit
for
building
up
IDs
around
languages,
but
they're
also
sort
of
building
their
own
compiler
and
in
a
sense
right,
so
that
that
allows
them
to
get
up
to
speed
very
quickly,
but
I
think
in
both
cases,
you're
somewhat
limited
in
what
you
can
do
in
terms
of
getting
very
precise
information
out
of
the
RUS
compiler.
B
B
C
In
Congress
out
of
time,
because
I
know
what
I
think
we're
already
over
time,
so
so
this
is,
it's
not
even
healthier.
This
is
pre-alpha
a
truss
cough
just
how
quickly,
how
many?
How
many
people
with
the
rough
call?
Okay,
it's
great
so
this
first
time
that
all
of
you
may
have
seen
this
Russ
cough.
We
showed
a
demo
of
what
this
would
be
like.
This
is
the
actual
RLS
running
now
so
I
can
hover
and
when
I
hover
I
get
type
information.
C
See
all
the
places
that
this
thing
is
defined
and
used
and
if
I
have
all
of
those
locations,
that's
awesome.
We
can
also
do
things
like
renaming.
We
have
perfect
knowledge,
so
if
I
wanted
to
call
this
position
instead,
you
see
all
the
position.
Paws
became
position
but
notice.
It's
not
textual.
So
POS
still
say
the
same.
So
we
know
exactly
where
that
symbol
is
being
used
and
we
quickly
again.
I
know
cognizant
of
time,
but
I
just
want
to
show
this
real
quick.
C
This
is
the
cool
power
of
open
source,
so
we
did
the
RLS.
It
worked
on
our
laptops
and
we
kind
of
put
it
out
in
the
world
and
then
let
other
people
start
banging
on
it
and
they've
already
ported
it
to
Windows
and
have
it
working
in
Windows.
So
this
is
the
same
experience
that
you
have
in
the
Linux
and
OS
10
world,
but
now
ported,
so
it
works
in
Windows.
A
This
is
the
most
important
part
of
the
talk,
because
this
beautiful
image
is
actually
a
fungus
and
it's
the
rust
fungus,
which
I
think
is
a
wonderful
thing.
I
didn't
realize
how
how
kind
of
attracted
it
would
be
when
I
went
looking
for
it.
So
there
are
a
bunch
of
other
teams
and
a
lot
of
other
efforts.
We
focused
on
the
language,
the
libraries
and
the
IDS
sort
of
technical
side,
but
there's
a
lot
of
other
things
right.
We
need.