►
Description
Aaron, Carol, and Niko will deliver an update on the state of all things Rust. You don’t want to miss it!
A
So
I
want
to
start
off
just
by
asking
how
many
people
are
here
for
the
first
time
at
any
rest
conference,
holy
cow.
That's
awesome.
Welcome,
so
we're
gonna
be
talking
a
bunch
about
community
throughout,
but
I.
Think
for
me,
the
greatest
source
of
joy
in
rust
is
its
community,
so
I'm
really
glad
you're
here
and
I
hope.
You
know
you
get
to
meet
some
of
the
existing
Russ
community
and
sort
of
feed
off
of
the
the
joy
and
excitement
that
is
rust.
A
Okay.
So
that
said,
let's
get
started
on
the
keynote,
so
the
this
keynote
is
going
to
sort
of
give
a
view
of
where
we
are
in
the
2017
cycle
of
rust
development.
So,
as
you
may
or
may
not
know,
the
way
that
sort
of
rust
development
is
set
out.
These
days
is
at
the
beginning
of
each
year
we
put
together
a
road
map
of
what
we
hope
to
accomplish
that
year.
That's
done
through
a
community
driven
RFC
process.
We
all
talked
about
that
roadmap
for
a
month
or
so
before.
A
You
know
finalizing
it
and
then
that
serves
as
a
sort
of
mission
for
the
year
that
we
continue
to
check
up
on
as
time
goes
by.
So
the
mission
we
set
out
for
2017
has
it's
sort
of
most
concise,
summary
making
productivity
a
core
value
of
rust.
So
that
is
you
know,
as
you
may
know,
rust
gives
you
performance.
It
gives
you
reliability,
but
if
it
has
one
weakness,
it's
probably
in
the
productivity
front
how
easy
it
is
to
learn
how
easy
it
is
to
find
quality
libraries
that
do
it.
A
You
know
what
you
need
and
so
on,
so
we
laid
out
a
whole
bunch
of
you
know,
sort
of
sub
items
under
this
heading
for
how
to
make
rust
a
more
productive
language
from
from
a
bunch
of
different
angles
and
I'm
not
going
to
go
through
all
of
these
right
now.
The
rest
of
the
talk
is
is
going
to
basically
delve
into
each
of
these
angles
and
where
we
are
what
we're
doing
so.
A
And
so
you
know
those
of
you
who
have
been
following,
you
know
might
like
to
know.
How
are
we
actually
progressing
toward
these
this
these
goals?
And
what
is
how
is
the
sort
of
flow
of
the
Year
gone
overall,
so
I
wanna
before
we
get
into
the
specifics,
I
want
to
give
you
another
piece
of
the
overall
structure
of
how
we've
approached
the
year.
So
in
particular
we
a
lot
of
the
things
we
wanted
to
do
this
year
involved
deep
design
word.
A
So
we
wanted
to
find
ways
to
make
the
language
easier
to
learn
by
actually
changing
the
language
and
that's
very
hard,
and
it
requires
chain
and
change
to
existing
things
is
something
that
is
often
very
contentious,
and
so
we
had
a
long.
You
know
design
focused
period
on
at
least
some
parts
of
the
roadmap,
but
we're
now
in
what
we
were
calling
the
imple
period,
which
is
you
know,
basically
no
new
design,
we're
focused
on
just
executing
on
our
plans
and
we're
about
a
third
of
the
way
through
the
simple
period.
A
So,
let's
see
so
I
see,
I
should
have
done
these
slides
there,
okay.
So
the
idea
is
yet:
throughout
the
year
we've
been
doing
sort
of
a
mix
of
design
and
implementation.
Now
we're
totally
implementation
focus.
So
one
of
the
really
cool
things
about
how
we've
set
up
this
imple
period
is:
it's
been
very
geared
toward
sort
of
community
participation
at
all
levels.
So,
once
we
had
a
clear
picture
of,
you
know
what
we
were
trying
to
do.
A
We
organized
that
into
35
working
groups-
and
this
seems
like
this
is
an
incredible
number
of
groups
doing
things,
but
actually
relatively
few
of
these
are
led
by
the
same
person.
So
this
is
just
gives
you
a
sense
of
how
much
activity
there
is
in
the
RUS
community
actually
attacking
this
roadmap.
So
each
of
these
working
groups,
you
know,
has
a
designated
leader.
It
has
a
dedicated
chat
channel
on
on
Gitter
and
the
leaders
have
put
a
lot
of
work
into
making
these
groups
accessible.
A
So
even
if
you
are
brand-new
to
rust
the
there's
a
place
for
you
here,
you
have
skills
that
rust
needs,
and
so
I
really
encourage
you
to
get
involved
in
the
info
period.
It's
been
a
lot
of
fun
and
will
will
again
be
seeing
some
of
the
results
of
it
later
in
the
talk,
so
one
other
thing
about
sort
of
the
overall
structure
of
the
year
and
our
plans,
so
you
may
have
heard
about
this
idea
of
epochs
and
I
just
want
to
sort
of
give
the
core
teams
perspective
on
on
what
epochs
are.
A
So
let
me
let
me
start
by
saying
you
know
you
probably
know
that
rust
has
a
rapid
release
cycle.
So
every
six
weeks
we
put
out
a
new
version
of
rust,
which
is
backwards
compatible
with
all
existing
versions
of
rust
and
I.
Think
this
release
cycle
has
served
us
really
well.
It
means
we're
sort
of
always
incrementally
improving
the
language.
We
don't
have
these
big
jumps
or
high-stakes
releases,
but
there
is.
A
There
are
some
downsides
to
that
approach,
because,
if
you're
not
following
rust
super
closely,
it
can
be
hard
to
understand
what
this
evolution
is
about.
Right,
you're,
seeing
all
these
like
from
it
from
a
distance,
you
see.
Okay,
ten
new
versions
of
rust
have
happened
like
how
do
I
understand
that?
What
does
that
mean
to
me?
What
version
should
I
be
using?
A
So
what
we're
trying
to
do
with
epochs
is
to
sort
of
layer
a
story
on
top
of
those
rapid
releases,
and
so
so
that
every
two
to
three
years
we
have
epoch
release
which
basically
says:
okay,
we've
done
a
ton
of
work
and
now
we're
we're
sort
of
choosing
a
synchronization
point
where
everything's
going
to
come
together.
All
the
documentation
is
going
to
reflect.
A
This
is
an
opportunity
to
put
all
that
together
and
again
synchronize
it
make
it
coherent
and
ship
it
to
the
world,
and
you
know
as
part
of
this,
we
we
will
also
have
the
ability
to
make
some
some
tweaks
that
you
know
involve
changes
to
existing
code
so
like
if
we
want
to
introduce
a
new
key
word.
You
might
have
been
using
that
key
word
as
an
identifier
in
previous
code,
but
we
are
very
committed
to
making
the
upgrade
process
as
smooth
as
possible.
A
So
this
is
an
entirely
opt-in
thing
and
it's
done
crate
by
crate.
So
it's
not
going
to
be,
like
you
know,
a
Python
2
versus
Python,
3
style
split,
and
we
put
a
lot
of
thought
into
how
to
make
this
as
smooth
as
our
incremental
really
cycle
has
been
okay.
So
with
that
I'm
gonna
hand
it
over
to
Nico
just
start
talking
about
the
specifics.
B
Hi
everybody
so
I
want
to
talk
about
a
lot
of
the
language
changes
that
we
have
been
making
or
planning
to
make
and
the
work
we've
been
doing
in
the
compiler
to
support
those,
and
also
just
to
make
the
compiler
nicer
to
use
and
one
of
the
first.
And
if
you
go
back
to
our
roadmap
goals,
the
one
we're
trying
to
attack
here
primarily
is
lowering
rusts
learning
curve.
But
the
way
we
decided
to
do
that
was
not
by.
B
We
didn't
want
to
do
things
that
would
solely
be
targeted
at
new
users,
because
sometimes
there's
this.
This
tendency
to
think
that
there's
kind
of
a
trade-off
where
you
can
make
the
language
easy
for
new
users
or
you
can
make
it
kind
of
good
for
experienced
users
who
know
what
they're
doing.
But
if
you
increase
one
group,
you
hurt
the
other,
but
what
we
noticed
is
in
fact
that
the
things
that
new
users
hit
and
find
hardest
to
learn
are
also
the
things
that
experienced
users
are
hitting.
B
They
just
learned
how
to
deal
with
it
and
they
can
solve
it.
But
it's
still
the
same
annoyances
arising
in
both
cases.
Right
and
so
what
we're
shooting
for
is
this
basically
changes
that
improve
the
ergonomics
of
the
language
that
make
it
as
an
experienced
user.
Just
reduce
the
friction.
You
experience
the
number
of
times
you
have
to
hit
compiled
because
of
small
nitpicky
errors
or
other
things
the
chance
that
the
code
you
write
will
work
good.
B
The
first
time
you
write
it
will
compile
well
and
for
but
that's
that
same
thing,
same
changes
really
like
disproportionately
benefit
new
users
as
well.
So
let
me
walk
you
through
some
of
them
and
we're
starting
to
see
them
land
on
nightly
now.
So
when
we
first
gave
this
talk
or
a
version
of
this
talk,
this
was
all
these
slides
were
saying.
Well,
we
kind
of
have
a
design
you
can
give
input
on
the
design,
but
but
now
we
get
to
see
some
progress
right.
B
So
so
one
example
in
working
with
matches
so
matches
are
one
of
the
best
features
of
rust.
You
can
deconstruct
enums
and
find
it
and
make
sure
you
handle
all
the
cases
you
need
to
handle.
But
if
you're
working
with
matches
over
borrowed
data
there's
a
lot
of
kind
of
small
changes,
you
have
to
make
to
make
everything
line
up.
B
Oh
and
I'm
borrowing
the
string
outside
of
the
option-
and
this
is
something
a
lot
of
people,
especially
in
the
beginning,
but
even
later
on,
find
difficult
to
get
right,
and
so
what
we've
instead
set
up
now
is
the
system
called
default,
binding
modes
where,
when
you're
matching
on
a
reference,
you
don't
have
to
write
the
star,
we'll
just
go
through
the
reference
for
you
and
when
we
go
through
a
reference,
we
know
that
you
must
be
borrowing
the
content
inside
right.
So
you
get
to
write
this
snippet
on
the
right.
B
This
lets
you
think,
more
about
the
types
you
just
sort
of
know
what
the
main
types
you
have
and
that
it's
borrowed
and
less
about
exactly.
How
is
the
compiler
reasoning
at
this
particular
place
and
makes
the
overall
experience
smoother,
and
this
is
actually
available
on
nightly
now,
if
you
go
and
enable
you
have
to
enable
the
feature
gate
but
I've
been
using
it,
it's
very
cool.
B
That's
thanks
to
a
contributor,
by
the
way,
to
be
a
shot
Dorf
who
implemented
it
and
another
similar
version
or
similar
in
some
sense,
in
the
sense
of
reducing
repetitive
content.
Is
we've
been
working
on
this
notion
of
implied
bounds?
So
one
thing
you
may
have
noticed
if
you've
implemented
generic
types
in
rust
is
that
you
often
have
a
kind
of
core
set
of
bounds
that
apply
to
your
generic
type.
B
So
you
might
say,
I'm
defining
a
set
and
the
things
in
the
set
can
be
any
type
T,
but
they
have
to
be
a
double
and
hashable
like
a
hash
set,
and
you
put
these
bounds,
maybe
on
your
type
and
then
you
have
to
repeat
them
everywhere
else,
which
is
kind
of
annoying
right,
so
I
usually
just
go
and
literally
copy
and
paste
it
from
place
to
place
and
then
make
sure
I
format
it
exactly
the
same.
So
I
can
easily
do
that
again
when
it
changes.
B
So
we've
been
working
on
improving
the
compilers
reasoning
system
so
that
you
just
say
the
bounds
once
when
you
define
the
type
and
then
everywhere
that
you
use
it
they're
implied
by
the
fact
that
the
types
already
said
that
they
have
to
be
there
right.
So
this
one
has
been
accepted
not
yet
implemented,
turns
out
to
be
a
little
tricky.
That's
okay,
we'll
figure
it
out
so
another
example:
a
kind
of
hotly
anticipated
feature
for
some
time
now
is
something
called
non
lexical
lifetimes,
which
is
a
kind
of
opaque
name.
B
But
what
it
basically
means
is
you.
It
makes
the
the
borrowing
system
in
rust
understand
your
control
flow,
much
better.
So
right
now,
let's
say:
I'm
a
map
like
I'm,
looking
up
in
a
hash
map
and
entry
for
a
given
key
and
I'm
borrowing.
The
result.
What
will
happen
if
I
store
the
result
of
that
borrow
into
a
variable
like
I?
Did
here
I
said:
let
value
equals
this
variable.
The
borrow
lasts
until
the
end
of
the
enclosing
block.
B
Usually,
as
a
result,
you
know
you
often
have
to
sort
of
introduce
artificial
blocks
so
that
you
can
end
the
borrow
when
you
wanted
it
to
end
right.
So,
if
you're,
just
gonna
use
the
value
in
the
next
line,
for
example,
here
I
just
used
it
in
the
if
and
don't
use
it
or
in
one
branch
of
the.
If
and
I,
don't
use
it
again,
that's
not
enough.
I
have
to
actually
pull
code
out
and
insert
blocks
and
then
I
can
make
it
compile
on
these
sort
of
contortions.
B
This
is
a
good
example
of
something
that
becomes
second
nature
when
you're
more
experienced
with
rust,
but
it's
really
not
obvious
if
you're
a
newcomer
right,
but
nobody
really
wants
to
do
it
in
the
first
place.
So
what
we're
doing
in
the
new
system
is
having
the
compiler
understand,
control
flow,
much
better,
which
means
you
can
actually
just
write
code
like
this,
which
can
look
up.
B
The
key
in
the
map
use
the
value
and,
after
the
last
use,
when
you
stop
using
the
thing
that
you
took
out
of
the
map,
it
it'll
be
free
from
mutation.
The
borrow
is
considered
to
end,
so
this
is
something
that's
underway.
Actually
Santiago
who's
here
in
the
audience
has
been
working
with
me
and
also
Paul
I'm,
not
sure
of
his
last
name.
Actually,
machinist
88
I
know
people
by
their
IRC
and
get
our
nicknames
usually,
but
and
we've
been
implementing
it
and
it's
kind
of
working.
B
You
can't
actually
use
it
yet,
but
there
are
tests
starting
to
pass.
So
this
is
on
its
way
as
well.
There's
also
a
much
bigger
effort.
I
should
add
around
supporting
this.
A
lot
of
people
are
involved,
and
another
similar
thing
in
the
sense
of
a
a
feature
that
enables
even
enables
and
eliminates
roadblocks
that
everyone
experienced
and
new
users
of
light
find
extremely
difficult
to
work
around
is
something
called
infiltrate
that
lets
you
handle
returning
things
like
if
you'd
like
to
return
an
iterator
out
of
a
function.
B
That
can
be
a
little
bit
difficult
right
now,
because
you
have
to
specify
the
entire
type
of
the
iterator,
which
might
be
very
long
or
if
it
includes
a
closure,
not
even
something
you
can
type,
and
so
what
we
do
now.
A
support
in
the
compiler
is
the
ability
to
say
I'm
returning
some
type
that
implements
iterator,
in
this
case
an
iterator
that
yields
up,
I,
32,
I'm,
sorry
you
32,
and
that
means
that,
even
if
it
has
closure
types
and
so
on,
you
don't
have
to
actually
tell
what
the
type
is.
B
The
compiler
will
figure
it
out
for
you.
So
we
have
a
preliminary
version
implemented.
We're
making
a
lot
of
improvements,
though
right
now
you
can
only
use
it
in
return
position
in
the
current
version
of
the
compiler,
but
under
the
expanded
and
intended
plans
we're
going
to
be
able
to
use
it
also
in
argument,
positions
and
other
places
to
say,
like
I'm,
taking
some
type.
That
is
an
iterator
without
having
to
introduce
a
generic
argument
and
do
these
other
things
and
async/await
is
another
kind
of
feature
like
this.
B
You
may
know
it
from
languages
like
JavaScript
ocean
sharp.
So
if
you're
writing
server-side
code
you'd
like
to
be
able
to
do
blocking
I/o
operations,
but
you
or
you
like
to
mail,
the
write
code
that
looks
like
you're
doing
blocking
I/o
operations,
I
should
say,
but
actually,
when
those
I/o
operations
are
happening,
your
function
returns
and
waits
for
the
results
and
then
starts
over
again,
and
you
can
do
this
by
hand
today
or
you
can
use
future
Combinator's
to
do
it,
which
sometimes
works
nicely,
but
a
lot
of
times
if
the
control
flow
is
complicated.
B
Today,
if
you
download
the
right
extensions,
you
should
talk
to
Alex
Brightman
about
it,
because
I'm
not
sure
what
you
have
to
setup
exactly,
but
so,
when
you
put
it
all
together,
I
think
you
can
start
to
get
the
feeling
that
Russ
2019
is
going
to
feel
like
a
pretty
different
language
right
and
so
I
only
talked
about
a
few
things.
These
are
some
of
the
proposals.
I
talked
about.
B
The
checks
are
the
ones
that
are
implemented,
at
least
in
some
form,
but
there's
a
lot
of
other
stuff,
and
this
isn't
even
a
complete
list
that
has
been
that
we've
been
planning
to
do,
most
of
which
is
in
some
form
of
is
in
some
way
a
part
way
through
the
implementation
process.
Someone
is
working
on
it,
some
of
the
ideas
that
we
had
didn't
work
out.
B
You
can
see
we've
crossed
a
few
out,
they
didn't
they
were
too
complicated
to
or
had
other
downsides,
but
overall
I'm
really
excited
to
see
what
Russ
2019
is
going
to
feel
like
and
I
think
you
should
be
excited
too,
and
if
you
want
to
help
us,
even
though
I
said
you
can
see,
there's
progress
there.
There's
still
lots
to
do
so
feel
free
to
reach
out
to
me
on
getter
I
will
find
you
something.
B
I
will
put
you
to
work,
don't
worry
speaking
of
that,
so
that
was
all
all
I've
been
talking
about
as
the
language,
but
to
make
all
these
features
happen,
they
have
to
be
supported
in
the
compiler.
So
we've
been
doing
a
lot
of
work
on
the
compiler
over
the
last
year
and
some
of
it,
especially
in
the
last
few
months,
has
been
this
feature
work,
but
before
that
there
was
a
lot
of
more
foundational
work
and
refactoring.
B
We
want
it
to
be
just
you
make
a
small
change,
it's
ready
for
you
right
away
and
we've
been
working
really
hard
on
instrumenting
the
compiler
to
make
that
happen,
but
we're
also
trying
to
support
things
like
constant
Eric's,
which
means
you
can
have
a
function.
That's
parameterised
over
a
value,
not
just
the
so
you
might
say,
make
a
different
copy
of
this
function
for
every
value
of
the
parameter
n.
B
So
when
n
is
1,
I
want
to
copy
specialize
to
that
and
when
n
is
2
and
4
and
8,
and
that
can
be
really
useful
for
high-performance
cases
and
procedural
macros,
which
let
you
not
only
use
the
built-in
macro
system
of
Rus
but
actually
write
macros
in
rust,
that
the
compiler
will
execute
it
sort
of
like
plugins
and
actually
that's
how
async/await
is
implemented
today.
So
you
may
have
saw
that
async/await
used
macro,
notation
and
stuff
on
the
other
slide.
B
That
was
using
a
prototype
of
the
procedural
macro
system,
so
the
code
is
written
to
do.
The
transformation
is
fairly
complex,
it's
written
in
rust,
but
a
single
weight
layers
on
top.
So
let
me
talk
a
bit
about
incremental
compilation.
This
has
been
something
we've
been
in
like
Nam,
Mexico
lifetimes
I
would
say
a
long
time
planned
and
coming,
but
turned
out
to
be
quite
challenging.
So
the
saga
begins
I,
don't
remember
when
it
was,
but
at
least
a
year
probably
two
years
ago,
with
RSC
1298.
B
This
basically
laid
out
a
plan
for
how
to
do
incremental
compilation,
and
then
we
went
ahead
and
we
we
implemented
that
plan.
We
made
a
beta
release
a
little
while
back,
and
you
know
it
worked
pretty
well.
So
if
you
look,
these
are
some
graphs.
The
details
aren't
that
important
just
have
to
look
at
these
big
red
lines.
Basically,
the
far
red,
far
red
line,
that's
how
long
it
takes
from
scratch
always
the
same,
but
each
of
these
rows.
B
B
However,
this
graphs
a
little
deceiving,
because
what
we
found
was
that
this,
although
it
was
working
pretty
well
when
it
worked,
there
were
a
lot
of
cases
where
the
system
has
planned,
wasn't
expressive
enough
and
we
weren't
able
to
get
much
better
than
this,
and
we
wanted
to
get
significantly
better
if
we
want
these
bars
to
be.
You
know
all
the
way.
B
Look
like
zero,
not
look
like
25%
of
the
time,
and
so
for
that
we
started
a
kind
of
new
design
that
we've
been
working
on
and
where
it's
actually
maybe
a
month
ago,
maybe
just
a
few
weeks,
I
lose
track
of
time.
Things
go
so
fast,
but
relatively
recently
actually
started
to
work
now,
and
we
call
this
red-green.
I
can
go
into
the
details.
Another
time
if
you're
interested
come
find
me,
it
enables
the
compiler
to
reuse
results.
Even
when
parts
of
the
input
have
changed.
B
C
C
So
no
starch
is
working
with
us
to
get
this
into
print
and
I
am
sorry
to
say
that
our
date
has
slipped
to
be
May.
So
it's
a
great
Mother's
Day
present,
but
it
is
coming
will
happen.
Someday.
Believe
me,
I
am
excited
as
you
to
see
this
in
print.
You
can
read
it
online.
Give
us
feedback,
especially
on
the
later
chapters
at
this
github
link.
C
Another
effort
we've
been
working
on
is
having
mentoring
available
at
all
levels.
So
the
the
working
group
said
the
info
period
are
a
huge
source
of
mentoring
and,
as
Nico
said,
there's
there's
room
for
everyone
here
and
we
will
find
something
for
you
to
do,
but
we
also
wanted.
We
want
to
grow
Russ
PI.
C
Another
effort
we've
been
doing
is
the
Russ
bridge
workshops.
This
comes
out
of
the
there
was
rails
bridge
and
there
are
many
other
bridge
workshops
in
other
languages.
These
are
try
Gurda
towards
under
representing
folks
in
tech.
We
had
one
yesterday
run
by
Ashley
Ashley.
Would
you
like
to
wave
and
if
anyone
who
was
at
that
workshop
yesterday
would
like
to
wave.
C
So
in
this
workshop,
everyone
builds
a
web
app
that
gives
you
emergency,
rust,
compliments
and,
and
we
hope
to
we
hope,
to
help
people
run
more
of
these
in
about
January,
Ashley
and
I
are
probably
going
to
hold
an
on
line
rust
bridge
teacher
training
to
help
people
feel
confident
about
running
one
of
these
in
your
own
community.
So
keep
your
eye
out
for
that
and
the
bridge
events
to
be
called
a
bridge
red.
You
have
to
be
targeted
towards
underrepresented
folks,
but
the
curriculum
is
online
and
free
to
use
for
anyone.
C
You
just
can't
call
it
a
bridge
event
if
it's
not
targeted.
So
this
is
an
example
of
making
thing
when
you
make
things
better
for
underrepresented
folks,
you're,
also
making
it
better
for
everyone.
Another
effort
we've
been
working
on
is
the
increasing
rusts
reach
program
where
we
brought
in
folks
that
have
experiences
and
insights
in
other
other
fields
like
teaching
and
other
languages
that
can
help
us
that
are
things
that
we
lack
experiences.
We
lack
in
the
Russ
community
and
bringing
them
in
to
help
us
make
rusts
better,
and
this
has
been
going
on.
C
C
Another
project
we've
done
is
the
request
for
explanation.
Podcast.
There
have
been
a
lot
of
RFC's
and
they're,
not
always
easy
to
keep
up
with
easy,
to
read
easy
to
understand
how
it
will
impact
you
so
Manisha
in
the
back.
If
you
would
like
to
with
Manish,
has
helped
with
this
effort
to
make
little
digestible
discussions
of
RFC's
to
help
everyone
keep
up
with
how
the
language
is
changing.
C
Another
effort
that
we've
been
working
on
is
making
high
quality
libraries
available
and
easy
to
find.
So
we've
been
in
order
to
do
that.
We
did
some
research
into
how
people
decide
what
crates
to
use,
and
we
found
that
the
the
most
important
thing
that
people
look
for
is
good
documentation
and
I
think
this
is
probably
something
in
hover
bears
workshop
yesterday,
that
that
was
reinforced.
That
good
documentation
is
like
the
first
interaction
people
have
with
your
library.
C
So
if
you
are
a
library,
author
I
would
highly
recommend
spending
some
more
time
on
your
Docs,
but
you
could
all
use
fedorov
and
there
are
a
lot
of
other
things
that
people
look
for
when
they're
looking
for
a
crate-
and
we
took
these
into
account
and
made
some
improvements
to
crates
I/o
this
year.
We've
added
categories
so
that
you
can
be
like
I
want
a
crate
that
does
this
and
you
can
go
to
the
this
category
and
find
the
crates
that
do
that.
C
We've
changed
the
sorting
to
be
recent
downloads
within
the
categories
and
the
keywords:
we've
added
some
badges.
So
you
can
see
if
the
crate
is
currently
passing
on
various
CI
things
on
Windows
and
on
Linux,
and
you
can
see
all
the
crates
that
a
particular
user
or
a
particular
team
owned.
So
you
can
see
which
crates
works
together.
Well,
for
example,
this
is
the
rustling
nursery
libs
team,
so
you
can
see
all
the
crates
that
that
team
is
working
on.
If
you
like
this
team's
work,
you
can
see
what
other
things
they've
made.
C
This
is
this
is
what
it
looks
like
if
you
haven't
happened
to
see
this
lately.
This
is
a
great
place
to
put
that
example
of
how
to
get
started,
using
a
library
to
see
what
it's
like
to
use
the
library
before
you
go
ahead
and
add
it
to
your
project.
You
download
it.
So
this
is
a
great
place
to
put
that
intro
documentation
to
help
people
use
your
crate.
A
So,
let's
talk
about
build
systems,
one
of
the
most
specific
goals
we
had
in
2017
on
our
roadmap
was
to
improve
the
story
for
build
system
integration
in
Rus,
and
this
is
particularly
important
for
you
know
larger
companies
who
have
their
own
take
on
how
they
want
builds
to
work.
They're,
often
using
big
build
systems
like
basil
to
do
all
of
the
building
across
all
of
the
languages
in
product
projects
at
the
company
and
they're.
You
know
have
been
various
points
of
friction.
Integrating
rust
into
that
story.
A
A
You
generally
use
the
whole
tool
chain
together
and
you
don't
really
care
about
these
distinctions,
but
when
you
want
to
bring
cargo
into
your
build
system
or
customize,
something
that
it's
doing
being
able
to
sort
of
peel
it
apart
and
replace
some
of
the
layers
and
keep
others
is
really
helpful.
So
I'm
just
gonna
walk
through
real
quick.
What
this
this
layering
is,
and
if
you
have
build
system
issues,
I
would
love
to
talk
to
you,
I'm,
always
looking
for
for
more
use
cases.
So
the
the
first
thing
that
cargo
does
is
dependency
resolution.
A
This
is
probably
the
single
most
opinionated
aspect
of
cargo,
where
you
know
we're
baking
in
the
way
we
think
about
semantic
versioning
and
so
on
and
after
the
pensive.
The
resolution
is
complete.
You
get
a
lock
file
right.
This
is
hopefully
familiar
to
many
of
you
if
you
use
cargo
much,
but
the
the
steps
after
this,
you
may
not
have
thought
about
so
once
you've
got
this
dependency
graph.
There's
still
a
bunch
of
steps
left
to
actually
do
a
build.
A
The
first
one
is
actually
figuring
out
for
each
crate.
How
do
you
want
to
build
that
crate?
What
what
kinds
of
knobs
have
you
tweaked,
and
these
these
knobs
are
at
the
sort
of
cargo
tamil
level
of
abstraction,
so
things
like
profiles
or
create
features,
or
you
know
configuring
particular
targets
so
on
and
so
forth.
A
A
So
each
of
these
pieces
is
something
that's
useful
in
different
settings
and
the
hope
is
that,
for
example,
if
you're
using
basil
and
you
maybe
you
don't-
want
dependency
resolution
or
build
configuration,
but
you
can
use
build,
lowering
so
that
you
don't
have
to
fully
grok
the
rust,
see
command-line
interface,
you
can
still
work
at
a
cargo
level
of
abstraction,
just
as
one
example.
So
I
think
this
is
a
really
interesting
area.
A
It's
still
very
much
in
development
and,
like
I,
said
I
would
love
to
hear
from
you
if
you've
encountered
friction
with
cargo
in
a
larger
build
system
setting
so
switching
gears.
One
of
the
things
we
saw
when
we
conducted
the
rust
survey
in
2016
that
I
think
surprised.
A
lot
of
you
know
the
people
in
the
rest,
core
team
was
the
importance
of
ID
es.
It
was
probably
the
single
most
requested
piece
of
tooling
and
for
many
people
blocker
to
using
rust
effectively.
A
So
you
know
in
in
the
last
year
and
a
half,
we've
really
put
a
lot
of
effort
into
the
IDE
story
and
there
are
now
multiple
IDs
that
are
quite
good
for
working
with
Russ
code,
so
one
of
them
is
IntelliJ
which,
a
few
months
ago,
actually
the
community
plugin
around
IntelliJ
for
us
became
an
officially
supported
part
of
the
IntelliJ
platform.
So
there
are
now
actually
multiple
people
working
full-time
IntelliJ
on
this
russ
plugin,
and
so
the
this
idea
is
really
great
and
it's
it's
making
a
lot
of
progress.
A
It's
also
part
of
the
Imperial.
If
you
want
to
act
on
it,
but
so
the
IntelliJ
approach
is
to
sort
of
that.
You
know
they
support
a
huge
range
of
languages.
They
have
a
lot
of
infrastructure
and
they
kind
of
have
their
own
way
of
doing
things.
They're
not
leveraging
the
rust
compiler
itself,
that's
not
sort
of
their
approach,
so
the
other
main
track
that
we've
been
exploring
is
something
called
the
Russ
language
service
which
speaks
a
protocol.
That's
used
in
vs
code
and
several
other
II's.
A
It
was
developed
jointly
between
Microsoft
Red
Hat
and
some
other
important
stakeholders,
and
so
basically
the
RLS
hooks
the
rust
compiler
up
to
this
protocol.
It's
sort
of
teaches
the
rest
compiler
to
speak,
the
the
language
that
these
IDs
want
to
use,
and
so,
as
a
result,
we
have
a
vs
code
plugin
for
Russ,
which
is
also
making
really
good
strides.
A
One
of
the
things
the
library
team
has
been
working
on
is
the
available
part
and
the
high
quality
part
right,
complementing
Carol's
easy
to
find
part,
and
so
we've
been
doing
this
through
a
program
called
the
libs
blitz
and
as
the
name
suggests,
the
idea
is
we're
going
to.
You
know
fairly
quickly,
go
through
a
lot
of
different
libraries
there.
There
are
a
lot
of
great
libraries
in
the
open-source
rust
ecosystem,
many
of
which
are
not
officially
in
a
sort
of
1.0
state,
but
there
are
morally
pretty
close
and
so
are.
A
Basically,
this
initiative
was
to
try
to
push
them
over
the
finish
line
and
actually
vet
them
according
to
a
set
of
guidelines.
So
we
we
picked
18
libraries
to
start
that
we're
all
in
the
state
like
pretty
close.
These
are
not
really
changing
that
much.
We
think
it's
feasible
to
try
to
get
these
to
a
really
solid
1.0,
and
these
are
also
relatively
foundational
crates
that
a
lot
of
other
crates
depend
on,
and
so
then
we
set
up
a
cadence
every
two
weeks.
A
We
would
target
another
one
of
these
libraries
and
we
would
go
through
a
public
discussion
during
those
two
weeks
where
people
could
talk
about
their
experiences
with
the
libraries
shortcomings
that
they
saw
questions
they
had,
but
then
also
we
have
a
sort
of
official
check
checklist.
That's
generic
across
all
libraries
that
just
sees
whether
they're
following
conventions,
whether
their
documentation
is
good
and
so
on
and
so
forth.
A
It
was
it's
been
incredible,
so
we've
been
making
really
really
great
rasaan
these
libraries-
and
you
know
I-
think
almost
all
of
them
will
in
fact
hit
effectively
1.0
status
by
the
end
of
the
year.
But
that's
not
all
one
of
the
things
I
find
most
exciting
about
this.
Is
we've
structured
it
in
a
way
that
by
the
end
of
the
year,
not
only
do
we
get
all
of
these
libraries
to
a
good
place,
but
we
have
this
byproduct
of
two
books
that
sort
of
come
out
of
this
process.
A
Is
there
an
easy
way
to
just
copy
paste
that
into
your
code
to
get
going
right?
I,
don't
know
about
you,
but
this
is
the
most
common
way.
I
first
interact
with
the
library
is
like
I
know:
oh
I
need
to
do
something
with
regular
expressions.
Let
me
find
an
example
that
looks
about
like
what
I
want
and
copy
that
in
so
this
is
going
to
be
I,
think
a
really
vital
resource
for
discoverability
in
ecosystem
and
we've
tied
it
nicely
to
the
Blitz
yeah.
A
So
I've
already
talked
about
the
sort
of
1.0
status,
but
it
feels
great
to
have
been
been
vetting
all
of
these
crates
and
I
think
by
and
large
they
are
looking
really
good
as
part
of
the
2017
plan.
We
also
had
some
specific
library
goals,
in
particular
around
the
server
networking
ecosystem,
which
is
one
of
the
places
that
rust
has
gotten
the
most
production
use.
So
far,
so
in
so
at
the
beginning
of
2017,
the
Tokyo
project
was
publicly
launched.
A
This
project
provides
a
sort
of
higher-level
async
IO
story
for
rust,
using
futures
as
Nico
was
talking
about
before,
and
it
is
being
used
in
in
production
today,
I
think
you
know,
an
ecosystem
has
grown
up
around
it.
This
is
the
first
part
of
the
story
we
wanted
to
tell
here,
but
there's
there's
a
lot
to
do
still.
So
one
thing:
we've
gotten
a
lot
of
feedback
on
over
the
course
of
the
year
is
that
Tokyo
is
difficult
to
learn.
A
A
So
there's
an
RFC
for
that
and
Alex
Creighton
has
been
doing
a
lot
of
great
implementation
work
there,
but
we
we've
got
so
much
more
in
the
pipeline,
so
there's
async/await,
which
was
mentioned
before,
and
we're
building
up
our
HTTP
stack
HTTP
to
support
is
on
the
way
and
perhaps
most
excitingly
there's
a
company
a
startup.
You
may
have
heard
of
called
buoyant,
doing
sort
of
very
sophisticated
proxy
servers
and
they
are
betting
very
heavily
on
rust,
so
they're
they're
now
funding
like
three
I
think
full-time
people
working
on
the
rust
open
source
stack
here.
A
So
this
is,
this
is
fantastic
and
I
think
you
know
we're
gonna
see
great
things
by
the
end
of
the
year.
Okay,
so
so
one
final
thing
for
me,
that's
probably
closest
to
my
heart-
is
growing.
Russ
leadership.
I
think
you
know
for
me
personally
it
it's.
You
know
if
you
go
back
and
look
at
that
slide
with
the
35
working
groups
like
getting
my
head
around
just
how
big
rust
is
and
how
much
leadership
that
requires.
A
C
So,
ultimately,
all
of
this
work
is
to
hopefully
increase
the
usage
of
rust,
because
I
think
that
would
make
software
better
overall
and
I'm
happy
to
say
that
we
are
seeing
some
increases.
This
is
a
graph
of
the
production
rust
users,
as
shown
on
the
rust
friends
page
which,
if
you,
your
company,
is
using
rust
in
production,
and
you
would
like
to
be
on
that
page,
you
can
send
in
a
pull
request.
C
C
But
silo
is
the
service
style
system
service,
the
experimental
browser
that
Mozilla
has
been
making,
that
is
all
in
rust
and
the
style
system
has
been
pulled
into
Firefox
from
servo
and
you
can
try
it
out
on
Firefox
nightly
and
the
Firefox
developer
version
and
beta,
and
it's
faster
everything's,
parallelized
and
red
nurse
really
quickly.
So
this
is
very
exciting.
It's
going
to
be
shipping
in
a
future
version
of
Firefox
in
production,
so
we're
all
really
excited
for
that.
The
number
of
crates
available
in
the
ecosystem
has
been
growing
as
well.
C
C
Let's,
let's
put
these
big
numbers
in
a
little
bit
of
context
here.
You
NPM
is
nodes
package
registry,
which
is
like
crates
I/o
and
they
have
their
graph
of
downloads.
And,
let's
see
where,
where
is
that
15?
Oh
yeah?
Ok,
all
right!
So
we're
not
in
the
big
leagues
yet,
but
this
this
is
actually
exciting
to
me,
because
we
here
are
all
still
in
on
the
ground
floor
rust.
It
is
growing
and
we've
got
a
lot
of
room
to
grow
and
room
to
make
Chris
IO
butter
before
we
get
set
p.m.
C
scale,
but
we're
gonna
get
there
someday.
But
so
the
answer
to
to
the
question
of
are
we
there
yet
is
a
resounding
no,
but
we
can
get
there
with
your
help
if
you're
thinking
about
getting
involved
now
is
a
really
great
time
with
all
the
working
groups
and
I,
we
have
a
lot
of
contribution,
opportunities
set
up
and
people
ready
to
help
you
contribute
and
we'd
love
to
have
you
please
join
us.
Thank
you.