►
Description
Opening Keynote by Aaron Turon, Carol Nichols and Niko Matsakis
Aaron, Carol, and Niko will deliver an update on the state of all things Rust. You don't want to miss it!
A
All
right,
hi,
everybody,
so
I'm
Erin,
and
welcome
to
the
second
edition
of
raw
stomp
before
I
start
I
want
to
mention
so
this
this
awesome
logo.
This
character
is
named
Lucy
in
case
you
were
wondering
and
I'm
sure
that
she
will
be
showing
up
in
future.
Rest
events:
this
is
a
awesome
artist
named
John
who's
been
doing
the
artwork
throughout,
and
so
we
really
love
it.
So
quick
show
of
hands
who
attended
the
first
rest
conf
last
year.
A
Awesome
welcome
back
and
welcome
to
a
whole
bunch
of
new
people,
so
I
asked
in
part
because
I
want
to
start
today's
talk
by
sort
of
recollecting
where
we
were
about
a
year
ago
when
we
were
giving
this
same
keynote
on
the
same
stage.
So
we
were
laying
out
the
idea
of
a
sort
of
roadmap
process
for
rust,
where
we'd
come
together
each
year
as
a
community
and
decide
what
our
vision
for
that
year
was
what
what
are
most
important
goals.
What
are
we
shooting
for
and
that
process
takes
into
account?
A
A
So
everybody
thinks
about
rust
in
terms
of
speed
and
reliability,
but
not
necessarily
productivity,
and
when,
when
we
look
at
the
survey
results,
when
we
did
our
planning
basically
making
this
a
third
pillar
of
rusts
story,
that
seemed
like
the
most
important
thing
we
could
do
this
year,
so
that
overall
vision
turned
into
a
whole
bunch
of
more
specific
goals
on
the
roadmap
which
we're
gonna
be
talking
about.
Basically,
throughout
today's
talk
like
where
are
we
on
these
things?
And
you
know,
I
should
I
should
call
out
specifically
the
lower
learning
curve.
A
I
think
was
the
single
clearest
message
that
we
saw
in
the
survey
that
people
were
bouncing
off
of
rust
because
of
the
initial
learning
curve,
if
they
could
make
it
through
that
they
would
fall
in
love
with
the
language.
But
we
really
wanted
to
do
more
to
make
it
easier
to
get
into
rust.
So
probably
a
lot
of
you
have
followed
the
roadmap
process
closely,
and
you
know
the
kinds
of
things
we're
doing
on
each
of
these
items
and
what
you're
wondering
you
know
like
any
long
trip.
A
Are
we
there
yet
so,
as
a
father
of
two
I'm
very
accustomed
to
hearing
this
question,
and
basically
the
talk
today
is
going
to
try
to
provide
you
with
a
long
answer
to
it.
So
talking
about
roadmaps
right,
let's
actually
look
at
a
little
bit
of
a
map
here,
so
you
know
we're
about
two-thirds
through
2017.
A
We
still
very
much
hope
to
achieve
what
we
set
out
in
the
roadmap
in
the
remainder
of
2017,
but
we're
sort
of
envisioning
a
couple
of
events
coming
up
in
the
future.
So
there's
something
called
the
imple
period
which
the
last
third
of
2017
is
going
to
cover
and
then
some
ideas
floating
about
something
called
rust
2019
coming
late
next
year.
A
So
let
me
tell
you
about
each
of
those
pieces:
okay,
so,
first
of
all
the
info
period,
so
you
know,
throughout
the
course
of
this
year,
we've
been
doing
a
lot
of
planning,
designing
RFC
discussion
about
how
we
want
to
solve
the
problems.
You
know
that
we
targeted
how
we're
going
to
actually
achieve
the
goals
we
set
out
to
achieve,
and
we've
also
you
know
in
parallel-
would
that
been
doing
some
implementation
work
along
the
way
right,
we're
a
big
community,
we're
doing
all
of
these
processes
together.
A
A
A
So
every
six
weeks
we
put
out
a
new
version
of
the
stable
compiler,
and
this
has
been
a
fantastic
model
for
shipping
software,
because
there's
not
this
mad
dash
to
get
anything
into
a
particular
release.
You
know
so
you're,
not
you're,
not
sort
of
always
in
these,
these
these
sprints
and
and
hurrying
tool
and
things
you
know
to
make
the
release,
because
if
you
miss
one
release
well,
the
next
one
is
only
six
weeks
behind
right.
A
So
it's
just
this
very
steady
process
where
rust
is
always
improving,
incrementally
a
little
bit
at
a
time,
so
I
think
I
think
it's
worked
really
well
for
us.
I
think
you
know
the
community
really
appreciates
it,
but
there
are
a
few
things
missing
from
this
release.
Model
and
I
think
the
most
important
thing
like
as
you'll
see
throughout
the
talk
today
with
what
we're
doing
on
the
roadmap.
A
We're
really
talking
about
in
some
a
lot
of
changes,
a
lot
of
improvements,
a
lot
of
stuff,
and
while
we
want
to
land
that
stuff
in
this
incremental
rapid
release
fashion,
we
also
want
at
some
point
to
sort
of
bring
it
all
together
into
a
coherent
polished
package
and
ship.
It
you
know,
give
it
a
name,
make
it
a
thing,
and
so
that's
the
big
idea
around
epochs
and
we'll
see
how
it
goes.
We've
been
thinking
about
this
as
a
sort
of
three
year
cycle
on
top
of
our
six-week
rapid
releases.
A
So
every
two
or
three
years,
probably
we
will
target
a
new
epoch
and
then,
in
in
that
cycle
you
know
when
we
do
an
epoch
release.
What
we're
trying
to
do
is
go
beyond
just
landing
the
bare
features,
but
actually
make
sure
that
we
have
the
book
or
the
books
up
to
date.
With
those
features,
the
compiler
is
producing
good
error
message
for
those
features.
Ids
and
other
tools
understand
those
features
and
how
to
work
with
them
and
the
ecosystem
is
starting
to
take
advantage.
A
So
it
sort
of
marks
a
new
chapter
in
Rus
development,
where
everything
is
coming
together
and
you
have
a
new
sense
of
of
what
rust
is
so
I'm
very
excited
about
this
and
I
think
this
is
also
a
really
useful
thing
for
talking
about
rust
to
people
who
are
not
following
it
so
closely.
So
it's
it's
easier
to
see
how
rust
is
evolving.
A
So
when
we
bring
this
all
together,
we
we
then
have
an
actual
flag
day
where
we
say:
okay,
the
next
epoch
is
coming
out
and
we
are:
we've
decided
to
label
those
with
a
year
so
we're
we
haven't
totally
decided
this,
but
thrust
2019
seems
plausible,
we'll
see
how
yours
roadmap
goes,
and
you
know
one
other
important
detail
here
is
as
we
are
outing.
You
know.
A
Various
new
features-
sometimes
we
need
to
do
things
like
introduce
new
keywords,
which
seems
maybe
innocuous
enough,
but
technically
adding
a
new
keyword
can
cause
problems
for
existing
code
right
if
that
existing
code
was
using,
that
word
as
a
variable
name
or
an
API
or
something-
and
you
know,
rust,
takes
stability
really
really
seriously.
That
was
our
big
promise
around
1.0,
and
so
we
want
it
to
continue
to
be
the
case
that
you
can
always
upgrade
the
compiler
and
your
code
will
keep
working
without
any
hassle.
A
So
when
we
do
things
like
introduce
new
keywords
or
make
other
sort
of
tweaks
to
the
language
that
could
cause
problems
for
older
code,
we're
going
to
tie
that
to
an
opt-in
and
you'll
opt-in
to
the
epoch
as
a
whole.
So
your
existing
code
on
the
sort
of
original
2015
Epoque,
which
is
what
you
what
you
all
are
using
right
now.
You
just
didn't
know
it
that
will
continue
to
compile
in
the
2019
compiler
without
you
having
to
do
anything.
A
But
then,
if
you
want
to
take
advantage
of
new
keywords
and
so
on,
you'll
be
able
to
mark
your
code
with
epoch,
2019
and
and
transition
to
it
right
and
the
other
cool
piece
of
this
is
that
you
can
mix
and
match
epoch
levels
in
your
dependencies
right.
So
there's
no
ecosystem
split
everything
keeps
working
and
can
work
together.
So
I
think
we're
really
excited
about
this
as
a
smooth
way
to
evolve
language
while
keeping
all
existing
code.
A
B
Ok,
so
hi
I'm,
Nico,
misaki's
I'm,
going
to
be
talking
about
the
language
and
the
compiler
and
I'll
start
with
the
language
kind
of
what
are
some
of
the
changes
that
are
coming
and
that
we
see
coming
for
that
have
already
been
planned
and
then
are
coming
now.
That
will
be
part
of
the
rest,
2019
concept
right
and
the
the
overall
idea
here
was.
B
B
So
let
me
just
kind
of
give
you
some
examples
to
make
it
more
concrete.
What
we're
talking
about
this
is
one
I
think
the
first
set
of
examples
are
cases
where
the
compiler,
essentially,
the
language
today
adds,
in
kind
of
extra
sigils
or
small
annotations
that
you
just
sort
of
have
to
add.
There's
not
really
a
lot
of
choice
around
it
and
we'd
like
to
make
that
easier.
So
something
like
match,
you
know
pattern
matching
is
a
really
powerful
and
awesome
feature
of
rust.
B
You
could
dive
down
into
your
structures
and
grab
out
little
pieces
and
so
forth,
but
sometimes
especially
with
references.
You
have
this
kind
of
incantation.
You
have
to
follow
right.
You
have
to
have
a
star
somewhere
to
go
through
the
reference,
and
then
you
need
some
refs
and
they
have
to
be
in
just
the
right
places
and
it
can
be
confusing
so
with
RFC
2005.
B
What
we
did
was
essentially
move
some
of
that
just
extend
the
way
match
work
so
that,
when
you
match
on
a
reference,
we
automatically
figure
out
that
you
must
need
a
reference
binding
for
example.
So
you
can
just
write
the
code
that
you
see
on
the
on
the
right
here,
and
everything
works
the
same
as
it
would
on
the
left
and
now
RFC
has
already
been
accepted,
and
implementation
is
kind
of
underway
actually
and
a
similar
example.
This
is
a
pending
RFC
2018
ein
for
implied
bounds.
The
idea
is,
when
you
define
types
in
rust.
B
Often
they
have
some
kind
of
constraints
so
like
in
order
to
be
a
set.
It
must
be
a
set
of
some
type
T
that
implements
EQ
and
hash,
and
then
that's
fine,
that's
a
good
thing
to
say
upfront,
but
that
every
time
I
use
the
type
set
I
have
to
repeat
that
right
and
it's
kind
of
just
there's
not
much
value
to
it,
because
it's
sort
of
implied
by
the
fact
that
even
any
set
must
meet
those
bounds
right.
B
So
it's
all
repetitive,
so
this
RFC
basically
allows
the
compiler
to
figure
that
out
and
says
if
you
define
some
bounds
on
the
struct
users
of
the
struct
kind
of
get
those
bounds
for
free.
So
you
don't
have
to
repeat
them
over
and
over
again,
but
those
two
changes
were
both
cases
where
there
was
really
only
one
right
thing
to
do,
and
you
kind
of
had
to
follow
that
path
and
the
compiler
would
lead
you
down
it.
B
But
there
are
some
other
cases
we've
seen
where,
in
order
to
get
your
code
to
work,
it's
more
than
just
adding
a
star
something
you
sometimes
have
to
do
some
bigger
restructurings
that
aren't
always
obvious
right.
So
a
classic
example
is
the
non
lexical
life
times
RC,
which
tinkers
with
and
improves
rusk
or
borrowing
system.
As
today,
the
the
length
of
a
borrow
is
always
tied
to
a
lexical
scope,
so
it
might
be
to
the
end
of
a
block,
for
example,
or
an
expression.
B
It's
exactly
the
same,
but
in
terms
of
its
ultimate
effect,
but
it's
just
simpler
and
smoother,
and
probably
what
you
wrote
in
the
first
place
before
you
got
the
error
message
so,
and
there
are
times
in
the
similar
vein,
where
the
amount
of
code
that
you
would
need
to
write
is
actually
so
high.
I
can't
really
show
you
on
the
slide,
so
you
don't
see
what
this
would
look
like
in
Russ
today,
but
a
common
example
is
when
you
want
to
return
something
like
an
iterator,
especially
something
involving
closures.
B
So
the
imple
trade
RFC,
which
is
partly
implemented
and
still
underway
for
some
parts
of
it,
allows
you
to
say
I'm
not
going
to
just
just
specify,
essentially
the
interface
or
the
trait
I,
guess
that
this
type
fulfills
right,
so
you
say,
I'm
returning
some
form
of
iterator
here
and
the
compiler.
The
caller
can
work
with
that
thing.
That's
all
they
need
to
know
they
can
iterate
over
it
and
then
compiler
figures
out
the
exact
type
and
that's
really
useful,
especially
for
closures,
because
there
you
have
a
type
that
you
couldn't
write.
B
B
So
these
are
the
kinds
of
changes
we're
talking
about
and
when
each
one
of
them
addresses
a
sort
of
specific
problem,
but
when
you
put
them
all
together,
so
those
are
the
ones
I
talked
about.
This
is
a
more
complete
listing.
It's
probably
not
the
full
set
of
RFC's
that
are
under
this
umbrella,
when
you
put
them
all
together.
I
think
the
language
is
going
to
reveal
a
lot
smoother
and
just
like
a
whole,
very
different
experience
and
we're
really
excited
about
seeing
it.
B
So
that's
what
we're
calling
now
rush
2019,
it's
kind
of
rust,
plus
these
various
changes,
so
here
I've
left
italicize,
the
ones
that
are
still
pending.
If
you'd
like
to
get
involved
in
discussion,
you
can
take
note,
but
this
is
the
plans
right,
but
then
there's
this
other
part
missing.
We
also
have
to
implement
all
these
plans.
So
that's
where
the
compiler
comes
in
right.
What
we've
been
doing
most
of
this
year?
B
One
of
the
biggest
changes
that
you've,
probably
heard
of
is
the
move
to
support
incremental
compilation
and
I'll
talk
about
that
in
a
little
bit
in
more
detail,
but
we're
also
doing
a
whole
bunch
of
other
things.
So,
for
example,
there's
a
lot
of
work
preparing
for
constant
Eric's.
Something
that's
eagerly
then
asked
for
by
many
people.
B
Basic
allows
you
to
write
functions
that
are
generic
not
over
a
type
but
over
a
value,
so
maybe
a
specific
integer
or
a
structure,
or
something
like
that
and
also
extends
the
constant
system
so
that
we
can
actually
evaluate
arbitrary
rust
functions
at
compilation
time
so
that
you
can
take
some
code.
That
would
have
run
at
run
time
executed
in
the
compiler
and
take
the
return
value
from
the
function
and
use
it
as
a
constant
in
your
code
and.
B
That
system
is
involves
well,
we'll
see
implementing
that
involved
reorganizing
the
compiler
in
a
number
of
ways,
but
it's
building
on
the
work
that
we
did
for
a
mirror
than
a
new
intermediate
representation
and
using
an
interpreter
and
so
forth.
It's
a
very
cool
thing
come
talk
to
me
later,
if
you're
interested,
but
the
last
part
I
would
mention,
is
the
procedural
macros
work.
That's
been
coming
through.
B
So
you've
probably
used
this
already,
because
it's
the
new
derive,
if
you're
deriving
for
using
Saturday
and
you're
deriving
serialize
and
so
forth
and
you're,
using
this
new
infrastructure
that
we
laid
out.
But
it
lets
you
essentially
write
Russ
code
that
runs
a
compilation
time
and
generates
Russ
code
for
the
compiler.
So
it's
kind
of
like
a
plugin
mechanism,
and
now
you
can
write
that
with
macro
rules,
today's
rust,
but
this
system
lets
you
write
arbitrary
Russ
code
to
do
it
and
we're
very
excited
to
see
that
grow
and
take
shape.
B
B
You
may
have
noticed
the
beta
release
came
out
at
some
time
ago
and
it
you
know
it
worked
pretty
well
so,
for
example,
if
you're
using
the
beta
release
to
build
the
Rex
crate,
we
made
various
changes
like
modifying
individual
methods,
and
you
can
see
here
this
chart
so
the
right
bar
at
the
far
right.
That's
how
long
it
takes
if
you
run
it
scaled.
So
it's
always
100%,
but
that's
how
long
it
takes
if
you
run
from
scratch
and
then
these
little
blue
bars
over
there.
B
That's
how
long
it
takes
when
you
doing
an
incremental,
build
and
you've
just
changed
one
little
thing,
so
it
worked
pretty
well
and
I
was
hoping
that
we
would
put
the
finishing
touches
and
I
would
be
up
here
telling
you
it's
all
ready
to
go,
but
life
intervened
and
we
wound
up
taking
a
slightly
different
and
slightly
longer,
but
I
think
very
exciting
path.
So
what
happened
was
in
order
to
support
things
like
Constantine
Eric's,
but
also
the
RLS,
the
rust
language
service,
the
IDE
support.
B
B
We
could
use
some
assistance
to
get
all
these
things
done,
so
there
are
a
lot
of
ways
to
get
involved.
If
you
want
to
be
involved
in
either
to
the
language
part
or
the
compiler
part,
or
both
I
mean
the
most
obvious
thing
is
we
have
a
lot?
We
need
to
get
these
designs
done
as
Erin
said,
and
we
need
to
get
started
working
on
them.
So
now
is
the
time
to
come.
B
Take
a
look,
see
the
RFC
s
that
are
pending
and
give
your
thoughts,
and
if
you
have
any
suggestions
on
how
to
improve
them
and
so
on,
but
once
they
land,
and
especially
during
the
imple
period.
This
is
a
perfect
opportunity
to
get
involved
in
hacking.
The
compiler
so
for
all
of
these
different
features,
I
hope
we
will
have
or
we
plan-
is
to
have
mentoring
instructions,
clear
ways
so
that
you
can
see
where
in
the
compiler
you
need
to
touch.
It's
not
like.
B
You
have
to
just
jump
in
from
scratch
and
I
will
add
something.
I
often
hear
people
think
would
suggest
that
the
compiler
is
like,
or
that
compilers
in
general
are
sort
of
a
wizardry
art,
but
you
know
it's
just
a
program
I
think
so,
if
you've
been
thinking
about
hacking,
compilers
or
you're
curious
how
they
work.
This
is
a
great
thing
to
do
right
now
and
of
course,
there's
also
work
not
just
on
the
rfcs,
but
on
incremental
compilation
and
the
other
ongoing
bigger
projects.
B
B
No
other
programs
ever
have
that
property
I
guess,
but
so,
if
you're,
if
you
have
hacked
on
the
compiler
a
great
way
to
help
or
is
to
help
us
prepare
for
this
info
period,
we
would
like
to
have
a
big
effort
to
kind
of
document,
not
just
what
in
the
compiler
does
what,
but
the
various
ways
that
one
builds
the
compiler
and
the
different
modes
and
flags
for
debugging
it,
and
so
on.
A
lot
of
that
work
is
underway,
but
I
think
it's
still
some
room
to
go.
B
So,
in
short,
please
I
hope
you'll
be
excited
about
all
the
big
changes
that
are
coming
up
and
the
improvements
we
have
in
store
and
if
you
would
like
to
get
involved,
we
are
really
eager
to
mentor
and
support.
You
can
look
for
the
existing
issues.
A
mentor
is
always
a
place
where
there
are
instructions
if
they
have
that
label
or
you
can
come
to
the
pound,
rusty
channel
or
just
ping
me
privately
and
we'll
find
something
for
you
to
do.
Don't
worry.
Thank
you
and
I.
Think
Carol
is
up
next.
C
C
As
Nico
said,
a
lot
of
the
ergonomics
initiative
is
focused
towards
lowering
this
learning
curve.
Another
big
project
that
is
underway
is
the
book.
Steve
and
I
have
been
hard
at
work
on
getting
this
book
ready
for
going
to
print
with
no
starch
press.
It
is
due
out
in
December
of
this
year
and
it's
the
perfect
gift
for
anyone
on
your
holiday
list.
It's
available
for
pre-order.
Now
it's
also
available
online
to
read
for
free
and
especially
the
later
chapters
that
haven't
been
all
the
way
through
the
editing
process.
C
We
would
love
if
you
would
read
those
give
us
comments
about
what
parts
are
good.
What
parts
could
use
a
little
more
work?
We
would
really
appreciate
your
help
with
that.
Another
goal
on
the
roadmap
this
year
has
been
mentoring.
People
at
all
levels
and
mentoring
is
almost
too
narrow
for
what
we've
done
so
far
this
year
and
what
we
plan
to
do.
C
What
has
been
proven
to
be
more
important
is
the
at
all
levels
part
of
the
goal
we
want
to
get
more
people
involved
with
rusts
in
all
parts
of
the
process
in
order
to
make
Russ
better,
especially,
we
want
to
grow
Russ
PI
by
bringing
in
folks
who
are
underrepresented
in
tech.
We
should
include
women
people
of
color
LGBTQ
people
with
disabilities,
because
they
also
tend
to
be
especially
underrepresented
in
assistance
programming.
C
We
think
Russ
is
an
enabling
technology
that
can
help
get
these
sorts
of
people
involved
and
we
can
make
rust
even
better
by
having
a
diversity
of
backgrounds
and
a
diversity
of
ideas
involved
in
making
rust
won.
So
there's
there
are
three
different
levels
on
this
slide.
The
first
one
is
helping
people
who
are
kind
of
new
to
programming
and
definitely
needed
rust,
and
one
of
those
efforts
has
been
a
rust
bridge
workshop.
The
bridge
events
concept
has
come
from
rails
bridge
and
there
are
now
different
bridge
events
for
lots
of
languages.
C
C
We
have
we
have
stickers
with
this
lovely
logo
that
Karen
made
for
us
with
Farris.
As
a
bridge,
we
went
through
an
introduction
to
rust
and
we
worked
on
making
a
web
app
in
rust.
That
gives
you
emergency
compliments.
If
you
would
like,
if
you
participated
in
the
rust
bridge
workshop
yesterday,
I
would
love
a
feud
wave,
so
we
could
say
hi.
C
Thank
you
for
coming.
It
was
a
lot
of
fun
yesterday,
we're
also
working
on
to
improve
the
website
for
the
workshop
and
make
assignment
kind
of
a
kit
so
that
anyone
can
run
one
of
these
workshops
in
their
communities
I.
In
order
to
be
called
a
bridge
event.
It
has
to
be
aimed
at
people
who
are
underrepresented
in
tech,
but
the
curriculum
is
available
for
free
online.
C
Anyone
can
use
it
just
don't
call
it
a
bridge
event
if
you
don't
meet
the
criteria,
so
this
is
kind
of
an
instance
of
working
to
make
things
better
for
underrepresented.
Folks
makes
it
better
for
everyone.
So
we
would
like
your
help
and
can
we'd
like
you
to
consider
running
a
bridge
event
in
2018
and
please
kind
of
like
the
community
team,
so
that
we
can
help
you
with
that
on
another
program
that
we
have
been
we
have
just
gotten
off.
The
ground
is
called
the
increasing
Russ
reach
program.
C
We
have
reached
out
to
people
who
are
under
episode
and
Tech
and
who
have
skills
and
expertise
that
we're
lacking
in
this
community.
So
people
like
professional
teachers
and
professional
designers-
we
just
don't
have
these
skills
around,
so
we
had
about
350
applicants
for
about
12
spots,
which
was
incredible
to
get
that
overwhelming
a
number
of
applications.
We
just
got
this
project
started
and
the
projects
ranged
through
a
variety
of
topics.
C
One
of
them,
for
example,
is
working
on
improving
and
adding
more
videos
to
the
to
rust,
calm,
screencast
series,
so
you'll
be
hearing
and
seeing
more
more
things
come
out
of
this
program
as
as
it
progresses.
This
is
going
to
be
running
through
October
and
we
hope
that
this
was
going
to
make
Russ
more
accessible
in
a
variety
of
ways.
C
Another
effort
is,
we
want
to
get
people
who
are
already
working
on
rust
involved
in
the
RFC
process
involved
in
shaping
how
Russ
is
going
to
progress
I
along
with
Manish
and
who
is
up
front
there
and
Alexi
has
started
this
podcast
called
request
for
explanation
where
we
discuss
an
RFC
on
the
progress
we
usually
have
the
author
of
the
RFC
on
and
I
think
it's
been
going
really
well
to
help,
because
RFC's
can
be
over
one
when
you
keep
up
with
there's
a
lot
of
them.
There's
a
lot
of
comments
on
them.
C
So
we
wanted
to
have
this
way
to
a
different
way
to
consume
this
content
so
that
everyone
can
keep
up
with
what's
changing
and
know
what
you
might
want
to
go.
Look
at
and
comment
on,
we're
thinking
about
other
ways
to
make
the
RFC
process
more
accessible
so
that
we
can
get
better
ideas
and
and
end
up
with
a
better
language.
C
So
another
goal
of
the
year
has
been
to
provide
good
quality
crates
and
make
them
easy
to
find.
So
to
that
end,
we've
made
a
bunch
of
improvements
to
crates.
I
owe
Jake
Goulding
and
I.
Actually
wrote
an
RFC
that
in
the
process
we
did
a
survey
that
asks
people
how
they
evaluate
which
crates
to
use
and
the
results
of
that
we
got
132
responses.
So
it's
not
it's
not
statistically
significant,
but
by
far
and
away
the
the
most
important
thing
is
good
documentation.
C
If
it
create
had
good
documentation,
people
wanted
to
use
it
more
so
crate
offers
take
note.
You
should
probably
work
cutting
to
Doc's
a
little
more.
There
are
a
number
of
features
and
number
of
things
that
people
looked
at
that
influenced
what
we
proposed
in
this
RFC
and
that
influenced
what
we've
implemented
so
far
this
year.
C
One
thing
we
shipped
was
adding
categories
so
yeah.
This
was
with
a
lot
of
feedback
from
the
community
about
which
categories
we
should
have.
These
are
meant
to
answer
the
question
of
I
needed
a
crate
to
do
something,
and
this
might
be
when
you
don't
even
know
what
you
should
be
searching
for.
Yet
you
don't
know
that
you
should
search
for
sturdy
to
get
something
that
will
serialize
in
to
a
certain
format.
We
also
have
keywords:
we've
had
those
for
a
while,
but
they're
kind
of
more
freeform.
C
Anyone
can
decide
to
add
any
keyword
categories,
our
have
a
specific
purpose
and
crate
authors
can
put
their
crates
in
various
categories
within
categories
and
keywords.
We
decided
through
the
RFC
process,
to
sort
by
recent
downloads
in
the
last
90
days
as
opposed
to
all-time.
This
is
meant
to
remove
the
bias
that
crates
that
have
happened
to
be
around
for
a
long
time
can
have
so,
for
example,
this
is
the
rust
patterns,
category
and
you'll
notice.
C
That
quick
error
has
more
all-time
downloads
about
400,000
error
chain
has
slightly
under
400,000,
but
in
the
last
90
days,
error
chain
has
been
downloaded
more
often
so
it's
listed
first
here
and
that
might
be
an
indicator
that
the
community
has
decided.
That
error
chain
is
a
better
choice.
Then
quick
error,
even
though
quicker
might
have
been
around
for
longer.
C
We've
also
added
the
ability
to,
for
crate
authors
to
add
a
variety
badges.
These
have
been
implemented
by
many
people
and
they're
displayed
on
with
your
crate
and
can
indicate
things
like
your
continuous
integration
results.
It
looks
like
curl
is
failing
on
App
there,
so
maybe
we
should
look
at
that.
C
Another
feature:
we've
added
is
a
the
ability
to
see
all
crates
that
are
owned
by
a
user
or
all
crates
that
are
my
team,
so,
for
example,
the
rustling
Nursery
libs
team.
You
can
see
all
12
crates
that
they
this
can
let
you
find
if
you
like,
a
particular
author,
you
like
their
work,
you
can
find
what
else
they've
worked
on
for
teams.
C
You
can
find
crates
that
are
meant
to
work
well
together,
so
you
might
have
noticed
that
these
are
not
really
related
to
documentation,
which
was
the
number
one
thing
and
I'm
pleased
to
announce
that
just
see.
Just
yesterday
we
deployed
a
really
awesome
feature,
and
that
is
rendering
the
readme
of
your
crate
on
crates.
I.
C
I
know
this
has
been
something
that
I
have
won
for
a
long
time
and
I'm
really
grateful
for
the
person
who
implemented
this,
and
so
this
will
let
create
offers.
You
can
add
what
what
this
crate
is
for.
What
it's
philosophy
is,
and
a
quick
example
I
think
is,
is
a
great
thing
to
put
at
the
top.
You
read
me
so
crate
authors
go
check,
your
read
means
make
sure
you're
specifying
it
and
your
cargo
travel.
Let
me
know
if
it's
not
rendering
but
I'm
very
excited
to
have
us
on
crates
ago.
C
Another
thing
that
might
be
coming
as
part
of
the
increasing
must
reach
is
a
crate
sigh,
a
redesign
which
now
that
we're
putting
all
of
this
information
for
you
to
use
when
deciding
what
crate
you're
gonna
use.
It's
it's
getting
a
little
cluttered,
so
we're
looking
to
clean
it
up
and
make
it
easier
to
find
the
information
you
care
about.
C
So
my
call
for
help
here
is
I
would
like
you
to
all
read
the
book,
especially
the
later
chapters
and
provide
feedback.
I
would
like
you
to
consider
running
a
rust,
reg
workshop
in
your
community.
We
always
want
ideas
for
from
the
community
for
which
RFC's
we
should
talk
about
on
the
podcast
and
we're
working
on
adding
a
whole
bunch
of
issues
with
the
emits
or
tag
on
crate
sia,
with
instructions
about
how
to
work
on
that.
C
A
So
one
of
the
things
you
know
again
going
back
to
the
last
year's
survey,
one
of
the
things
we've
heard
a
lot
for
people
trying
to
use
rust
in
the
context
of
a
larger
organization
is
that
they
love
cargo.
They
really
want
to
use
the
crates
I/o
ecosystem,
but
they
were
feeling
friction
integrating
cargo
into
their
big
build
system
right.
A
So
if
you've
heard
of
things
like
basil
or
buk
stuff,
like
that,
it
wasn't
always
clear
exactly
how
crates
ioud,
how
cargo
should
fit
into
that
picture,
and
so
we've
been
spending
a
lot
of
time
this
year,
trying
to
understand
first
what
the
problem
is
and
that's
been
a
little
bit
harder
than
you
might
imagine,
but
recently,
we've
kind
of
put
together
that
part
of
the
reason
this
has
been
so
hard
to
get
a
handle
on
is.
There
are
really
two
very
different
kinds
of
customers
for
build
system
integration.
A
So,
on
the
one
hand
you
have,
you
know,
places
that
are
maybe
using
a
variety
of
build
systems
already
they
are
more
or
less
okay
using
cargo,
but
maybe
there's
some
aspect
of
cargo
that
they
need
to
customize
or
fit
a
little
bit
better
into
their
build
system
right.
So
a
very
common
request
is
I
love
using
crates,
I
owe
for
the
open
source
ecosystem.
A
But
you
know
my
company
needs
to
have
some
closed
source
crates
or
whatever
I
would
love
to
have
the
same
model
right,
but
have
my
alternative
crate
registry
locally
or
I
need
to
control?
Caching
of
you
know:
I've
pre-built,
artifacts
or
whatever
many
of
these
other
things.
The
point
is
most
of
these
folks
are
more
or
less
okay
with
cargo,
but
there's
just
some
particular
point
of
friction.
That's
preventing
it
from
being
a
smooth
experience.
A
So
customer
number
two
is
also
interested
in
customizing
a
sort
of
set
of
features,
but,
unlike
customer
one,
they
really
want
to
control
absolutely
everything,
and-
and
so
this
is
the
case
that
tends
to
come
along
with
highly
opinionated
and
structured,
build
systems
that
are
already
controlling
all
of
these
aspects
and
basically,
when
you
integrate
some
other
build
process
into
it,
you
want
it
to
to
yield
to
to
the
larger
build
system
so
that
you
have
this
sort
of
consistent,
workflow
and
experience
across
the
board,
and
so
we've
realized.
You
know
like
picking
apart.
A
These
two
different
customers
has
been
really
helpful
in
in
understanding
the
space
and
how
we
should
approach
it.
And,
of
course
you
know
the
interesting
thing
and
notice
here
is
that
the
actual
lists
of
customizations
that
these
two
customers
want
is
the
same.
But
there's
this
critical
difference
where,
as
customer
one,
maybe
you
you
only
need
to
provide
one
new
feature
to
cargo
and
then
they
are
unlocked
and
you
have
improved
life
for
them
for
customer
to
until
they
can
control
everything
there.
A
They
have
nothing
basically,
and
so
what
we've
been
trying
to
work
out
is
basic
is
how
we
can
serve
both
of
these
customers
at
the
same
time
in
a
sort
of
incremental
way.
So
for
customer
one,
that's
not
too
hard
right.
As
long
as
we
are
shipping.
These
new
features
on
a
regular
cadence.
More
and
more
of
those
kinds
of
people
will
have
a
friction-free
experience
with
cargo,
but
to
unlock
customer
two,
we
we
need
to
understand
the
essence
of
cargo
and
what
it
means
for
an
external
build
system
to
drive.
A
But
after
you
do
dependency
resolution,
you
get
a
lock
file
and
there
are
number
of
steps
remaining
all
right.
So,
conceptually
after
the
log
file,
you
can
sort
of
take
the
configuration
in
various
cargo
Hummels
involved
and
paint
the
dependency
graph
figure
out.
Actually,
what
are
the
profile
settings?
What
kinds
of
features
are
enabled,
etc,
etc.
A
So
this
is
figuring
out
how
to
configure
each
crate
in
the
breadth
at
the
cargo
level
of
abstraction,
then
there's
another
step
which
we're
calling
calling
a
build,
lowering
where
you
lower
the
level
of
abstraction
down
to
actual
calls
to
rust,
see
with
a
whole
bunch
of
flags.
Maybe
running
some
binaries,
you
know
if
you're
producing
build
scripts
and
so
on
and
so
forth.
So
then
the
idea
is
for
customer
number
two
for
the
the
hard
case
to
give
them
the
control
that
they
want.
You
know
to
let
them
make
progress
right
away.
A
It
could
produce
Basile
rules
or
whatever,
and
now
the
integration
is
pretty
smooth,
and
now
this
rusts
on
work
that
has
already
happened
around
things
like
dependency
resolution
to
let
people
vendor
crates
locally
and
have
their
own
mirrors
and
so
on,
and
the
idea
in
the
long
run
is
that
the
work
we're
doing
here
and
the
work
we're
doing
for
customer
one
will
sort
of
converge.
Once
we
have
higher-level
ways
to
customize
each
aspects
of
the
build,
maybe
you
no
longer
need
to
spit
out
this
low-level
build
plan.
A
Maybe
the
integration
is
smoother,
but
but
with
this
strategy
we
at
least
unlock
that
customer
number
queue
right
off
the
bat
and
let
them
make
progress
all
right
going
again
back
to
the
survey.
One
of
the
really
clear
messages
we
got
last
year,
which
took
us
a
little
bit
by
surprise,
is
that
people
really
like
IDs,
especially
people
not
using
rust,
so
I,
think
it
was
something
like
I.
A
So
there
was
a
particularly
exciting
announcement
just
earlier
this
month
that
the
IntelliJ
plug-in,
which
has
been
developed,
sort
of
in
a
volunteer
or
open
source
style
for
a
while,
is
now
becoming
an
officially
supported
part
of
the
IntelliJ
IDE,
which
means
you
know
higher
resourcing
and
so
on.
So
I
wanted
to
thank
Alexei
in
particular,
who's
been
doing
a
lot
of
that
work
for
making
this.
A
A
It
works
for
lots
of
languages,
and
you
know:
they've
been
working
on
building
rust,
support
sort
of
from
from
the
ground
up
in
that
setting,
but
the
other
strategy
we've
been
taking
is
with
what
we
call
the
rust
language
service,
and
this
is
something
that's
actually
built
into
the
compiler,
where
basically,
we
turn
the
compiler
into
an
API.
That
external
tools
like
IDs
can
peer
into
to
get
information
for
auto
completion,
refactoring
and
lots
of
other
things.
So
this
work
was
spearheaded
by
Nick,
Cameron
and
Jonathan
Turner.
A
A
So
that's
the
IDE
story,
another
major
theme,
of
course,
if
you
want
to
talk
about
productivity,
you
have
to
have
libraries-
and
this
is
especially
true
for
rust,
because
we've
taken
a
pretty
lean
approach
to
the
standard
library,
mostly
in
the
interest
of
not
over
committing
not
over
coupling
and
since
cargo
makes
it
so
easy
to
include
dependencies.
A
lot
of
the
good
stuff
is
out
there
in
the
in
the
larger
crates
I/o
ecosystem.
A
So
that's
been
a
good
model,
but
for
it
to
really
work,
we
need
to
make
sure
that
that
ecosystem
includes
the
libraries.
You
need
that
they're
highly
polished,
that
you
can
find
them
and
so
to
pull
that
off.
The
libs
team
this
year
has
been
undergoing
what
we're
calling
the
libs
blitz
and
is
Brian
Anderson
in
the
room,
No,
okay,
so
Brian
Brian
sort
of
spearheaded
this
David
told
me
has
also
been
then
helping
a
lot
and
so.
A
So
so
let
me
tell
you
about
what
this
process
looks
like,
so
we
targeted
18
foundational
libraries,
mostly
foundational
some,
some
that
are
a
little
bit
higher
level.
So
these
these
libraries
are
widely
used
in
the
ecosystem.
They,
you
know,
they're,
doing
sort
of
low-level
very
important
tasks
and
we
set
out
to
improve
all
of
these
libraries
over
the
course
of
the
year
and
the
way
we
did
that
is.
A
We
set
a
cadence
where,
over
the
course
of
36
weeks
every
two
weeks,
we
would
be
looking
at
a
different
one
of
these
libraries
as
a
community,
and
so
we
have
a
public
evaluation
process
where
we
have
a
dedicated
internals
thread.
We
look
from
soup
to
nuts
at
the
the
API
design,
documentation
and
everything
else,
and
then,
at
the
end
of
that
process,
the
library
team
meets
to
talk
about
the
thorny
or
issues
that
were
raised.
A
Then,
after
that
meeting,
the
outcome
is
turned
into
a
whole
bunch
of
issues
open
up
against
the
library
and
a
bunch
of
PRS
closing
those
issues,
and
this
has
been
an
amazing
community
success,
as
with
so
many
other
things
in
rusts.
Basically,
we
can't
keep
these
issues
coming
fast
enough,
so
so
these
libraries
have
seen
a
ton
of
activity
as
part
of
the
blitz
and
that's
been
super
exciting,
but
wait
there's
more
so
one
of
the
really
cool
things
when,
as
a
byproduct
of
this
process
is
that
we're
producing
essentially
two
books.
A
So
the
first
one
is
a
book
about
rust,
API
design,
and
this
lays
out
a
bunch
of
principles
for
how
you
should
set
up
your
public
API
you
in
a
rust
crate
and
it's
been
the
backbone
of
the
library
evaluation
process.
So
we've
been
sort
of,
we
started
with
some
initial
sketch
of
this
book
when
we
started
the
process,
but
then
we
use
it
to
evaluate
crates
as
questions
come
up
about
crates
that
are
not
addressed
in
the
guidelines.
We
use
that
to
inform
improvements
to
the
guidelines.
A
So
it's
been
this
very
you
know,
synergistic
process
producing
this
book
and
so
by
the
end
of
the
year,
we'll
actually
have
a
sort
of
first
edition
of
this
ready
to
go
and
then,
in
addition-
and
this
kind
of
goes
back
to
you,
the
documentation
points
that
Cara
was
talking
about.
We
are
building
a
rust
cookbook,
so
for
each
of
these
libraries
we,
you
know
again
collectively,
as
a
community,
come
up
with
several
small
examples
that
show
important
ways
to
use
the
library
so
that
you
can
quickly
get
up
to
speed.
A
When
you
want
to
try
out
a
library,
there's
code
samples,
you
can
you
can
copy/paste
and
you're
off
to
the
races.
So
this
is
I
think
one
of
the
key
ways
that
we
can
deliver
a
batteries
included
experience
for
rust,
even
though
the
batteries
are
not
in
the
standard
library,
they're
sort
of
out
there
in
the
ecosystem.
As
long
as
you
know
where
to
find
this
book,
you
can
find
your
way
to
some
of
the
best
libraries
out
there
and
then
the
in
some
sense.
A
The
the
final
goal
for
the
libraries
at
the
end
of
the
day
is
what
we've
been
calling
sort
of
1.0
status.
That
doesn't
necessarily
mean
literal
1.0
version,
some
of
the
libraries
actually
we're
already
above
one
we
know.
But
what
we
really
mean
is
that
we
have
picked
the
tires.
The
library
team
has
given
a
stamp
of
approval
according
to
the
guidelines
and
other
issues
that
were
raised,
you
can
expect
you
know
relative
stability
of
the
library,
so
no
no
major
breaking
changes
planned
and
you
know
bottom
line.
This
crate
is
ready
for
use.
A
A
Now
we
targeted
one
specific
part
of
the
ecosystem
in
this
year's
roadmap,
which
is
the
server
and
networking
use
case
in
rust,
particularly
around
really
high
scale
servers,
and
this
was
something
both.
That
was
mentioned
a
lot
in
the
survey,
but
also
where
we're
seeing
a
lot
of
production
use
of
rust
in
this
space
already,
and
so
we're
really
eager
to
unblock
further
production
use
and
enhance
the
experience
of
those
users.
So
you've
probably
heard
about
the
Tokyo
project,
which
is
an
async
IO
library
in
rust.
A
That's
based
on
futures,
API
Tokyo
was
released
at
ODOT
one
at
the
beginning
of
2017
and
there's
been
a
lot
of
work
since
then.
Building
up
you
know
a
larger
ecosystem
around
it
and
Turkey
is
already
being
used
in
production
today.
So
I
think
this
has
been
a
very
exciting
and
important
step
forward
and
Russ
story,
but
I
very
much
wants
to
acknowledge
that
it's
not
finished
in
the
sense
that
there's
been
a
lot
of
feedback
as
people
have.
You
know
taking
a
look
at
this
library
that
it's
hard
to
learn.
It's
complicated.
A
You
know
it's
tricky
stuff
and
we
take
that
very
seriously
and
part
of
the
plan
for
the
rest
of
the
year
is
to
take
a
lot
of
steps
to
lower
the
learning
curve
on
this
library,
just
like
we're
doing
for
rust.
So
we're
going
to
do
that
in
a
few
ways.
We
have
a
really
awesome,
API
revamp
in
mind
as
of
this
week,
and
there
will
be
an
RFC
actually
coming
about
that.
You
know
I
hope.
A
If
you've
tried
took
you
in
the
past
and
struggled
with
it,
you
can
check
out
that
RFC
and
and
tell
us,
oh
yeah,
that
would
have
made
my
experience
a
lot
better.
In
addition,
we
plan
to
totally
revamp
the
Docs
right,
a
lot
more
examples
and
just
make
it
a
lot
easier
to
get
started
in
Tokyo
Alex
over
there.
A
So,
of
course,
alex
has
been
a
huge
part
of
this
project,
and
so
many
others,
but
in
particular
he
sort
of
made
it
a
mission
to
get
to
make
async/await
a
thing
in
rust
as
soon
as
possible.
So
this
is
something
that,
as
Nico
was
saying
before,
can
go
a
long
way
to
making
a
scene
Kyoto
more
usable
and
Alex
has
figured
out
how
to
carve
a
path
to
async/await
on
nightly
rust
any
day.
A
Now,
there's
one
PR
that
still
needs
to
land,
but
as
soon
as
as
soon
as
we
get
that
at
least,
if
you're,
using
nightly
rust,
I
think
that
the
Tokyo
experience
will
be
much
smoother
and
we
hope
to
push
towards
stabilization
of
this
as
soon
as
possible.
Okay,
and
in
addition
to
that,
there's
lots
of
great
stuff
going
on
in
the
ecosystem.
So
a
few
weeks
back,
the
HTTP
crate
came
out
which
gives
you
a
bunch
of
standard
types
like
request
response,
header
maps
and
so
on.
A
That
just
provides
a
common
vocabulary
for
anything
that
wants
to
talk
about
HTTP
hyper,
which
has
been
around
for
a
long
time,
is
now
hooked
up
to
Tokyo
and
soon
will
be
hooked
up
into
this
new
HTTP
crate
and
then
very
recently,
a
new
library
called
h2
was
publicly
released,
which
is
an
HTTP
to
implementation
by
a
car
alert.
Carl.
Are
you
here,
Thank
You,
Carl.
A
And
a
really
exciting
part
of
this,
so
so
Carl
recently
started
working
at
this
company
employment
who
has
a
product
very
deeply
based
on
a
sink
I
know,
and
they
are
really
looking
at
a
trust
and
sort
of
pivoting
toward
rust
as
a
way
of
taking
their
product
to
the
next
level.
So
they
were
dealing
with
their
previous
library.
A
So
I
expect
you
know
over
the
next
year
to
see
a
lot
more,
really
key
libraries
getting
financial
resources
behind
them
in
the
open
source
world,
which
is
super
exciting
all
right.
So
one
last
piece
for
me:
taro
talked
a
bunch
about
mentoring,
especially
sort
of
people
who
are
new
to
rust
in
various
ways,
but
we've
also
been
working
on
mentoring
within
the
community
and
especially
growing
rusts,
formal
governance
structure.
A
So
I
think
you
know
in
a
sense,
I've
been
saying
recently
to
Nico
that
I
think
in
some
ways
the
rust
project
has
just
gotten
bigger
faster
than
any
of
us
really
anticipated,
and
it's
been
a
struggle
to
keep
the
the
leadership
structure
and
the
governance
structure
at
scale
with
the
growth
of
the
project.
But
we've
made
some
really
big
strides
this
year.
So
you
know
a
lot
of
these
mechanics
maybe
are
not
evident
if
you're
not
watching
closely
but
I
just
wanted
to
walk
through
a
few.
A
A
So
there's
a
cargo,
a
team,
dedicated
cargo,
one
for
infrastructure
and
one
for
dev
tools,
and
this
allowed
us
to
bring
a
whole
bunch
of
more
people
onto
each
of
these
teams
and
made
each
of
them
more
focused
on
a
particular
task
and
I
think
this
has
been
working
extremely
well.
You
know
I
feel
like
we're.
We've
unblocked
a
lot
of
stuff
as
a
result
of
this
and
brought
a
lot
more
people
into
project
leadership.
A
We've
also
grown
the
core
team
itself,
with
Carol
being
one
of
the
members
this
year,
as
well
as
Nick,
Cameron,
who's
heading
up,
the
dev
tools
team
and
finally,
we
have
been
exploring
ways
to
add
intermediate
steps
on
the
way
to
formal
team
membership.
So
team
members
generally
are
the
ones
who
are
the
final
deciders
on
our
FCS
on
a
consensus
based
process.
A
But
we
want
people
who
can
work
with
the
teams
and
attend
meetings
and
sort
of
be
involved,
but
not
necessarily
have
that
final
decision-making
role,
and
so
that
looks
differently
for
the
different
sub
teams.
Sometimes
we
call
them
peers,
sometimes
shepherds,
but
it's
been
incredibly
effective
this
year
and
a
huge
source
for
growth.
So
you
can
see
the
the
numbers
here.
We've
added
a
lot
of
peers
and
we
plan
to
keep
going
with
that
and
then
a
final
note.
A
So
going
back
to
our
general
theme
around
the
imple
period,
absolutely
everything
I've
talked
about
is
desperate
for
your
help.
Let
me
give
you
a
bit
of
detail
on
that.
So,
on
the
on
the
cargo
side,
there's
a
lot
to
do
on
cargo,
but
for
build
plans
specifically
we're
still
hammering
out
the
design
of
the
build
plan
format.
So
if
you
are
a
stakeholder
in
this
area,
if
you
have
a
build
system,
you
would
like
to
see
cargo
integrate
with.
A
So,
on
the
on
the
ide
side,
I
should
have
had
IntelliJ
here
as
well,
but
I
already
told
you
you
should
try
it
out,
but
also
the
RLS,
we're
hoping
to
ship
a
beta
soon,
as
I
said,
and
we
need
as
many
eyes
on
it
as
we
can
get,
because
you
know
there
are
lots
of
subtle
bugs
that
can
arise.
So
if
you
can
help
us
find
them
and
report
them.
That's
super
helpful
and
Nick
has
done
a
great
job,
creating
mentored
issues
here
as
well.
A
If
you
want
to
actually
hack
on
the
RLS
itself,
the
Lib
splits
is
like
completely
designed
for
community
involvement,
but
we
can
always
use
more.
So
both
the
cookbook
and
the
guidelines,
you
know,
are
there
and
growing,
but
they
can
always
use
more
work.
There
are
tons
of
open
issues
on
both
of
them
and
there
are
still
library,
evaluations,
ongoing
and
we'd.
A
Welcome
your
participation
in
those
and
we'll
have
more
to
say
going
into
the
inkle
period
about
other
ways
you
can
help
and
with
Tokyo,
as
I
already
said,
we're
gonna
have
an
RFC
soon
feedback
and
discussion
on.
That
would
be
extremely
helpful
and
helping
with
the
docs
would
also
be
great,
especially
if
there
are
examples
you'd
like
to
see.
You
know
that
you
could
work
with
us
to
help
figure
out
and
then
make
part
of
the
dogs
and,
in
general,
you
know,
I
think
we're
at
the
early
days
of
the
async
I/o
ecosystem
in
rust.
A
C
So,
as
Erin
mentioned,
the
teams
are
growing
and
rust
is
growing
and
there
are
a
few
other
ways
that
we
can
see
how
rust
is
is
growing
lately.
One
of
those
is
the
production,
rust
users.
This
is
the
graph
of
how
many
logos
we
have
on
the
rust
friends
page
since
that
page
was
created.
The
this
started
in
April
27
2016,
and
we
are
now
off
to
88
companies
that
are
using
rust
in
production.
C
One
of
our
biggest
production
users,
of
course
Mozilla
it
was
Firefox,
is-
has
an
exciting.
The
upcoming
milestone
they're
shipping
stylo,
which
is
servos
parallel,
CSS
rendering
engine
in
Firefox
57
it's
available
in
nightly
right
now,
if
you
turn
on
the
flag,
I've
been
using
it
for
a
few
weeks,
and
it's
incredible.
It's
it's
very
fast,
I
I
know
there
are
some
members
of
the
service
team
in
tennis,
would
you
wave
or
stem
so
we
can
like.
C
C
That
sounds
like
a
pretty
big
number
right.
Let's,
let's
put
that
in
perspective,
you
may
have
seen
this
tweet
from
Laurie
Bose
who
works
for
nvm
who,
by
the
way,
is
a
Russ
production
user
and
they
tweeted
out
there
download
stats
by
month,
and,
let's
see
where
does
15
million
go
Oh
yep
right
yeah,
so
so
we're
still
pretty
small
potatoes
in
the
grand
scheme
of
programming
language
ecosystems.
But
this
is
actually
exciting
to
me,
not
depressing
we're.
C
Still
in
the
ground
floor,
all
of
us
we're
still
creating
the
ecosystem
that
is
going
to
be
around
for
a
long
time.
We
still
got
room
to
grow
and
we've
still
got
time
to
improve
crates
I/o
before
word
NPM
scale,
and
so
the
answer
to
the
question
that
Aaron
posed
of
are
we
there
yet
I-it's
a
resounding?
No
we're
not
there
yet,
but
there's
good
news.
We
can
get
there
with
your
help.
We've
shown
a
whole
bunch
of
ways
that
we
would
love
to
have
your
help
in
about
a
month.