►
From YouTube: Emily Dunham - Keynote: Spreading The Rust
Description
Today you’ve gotten inspired by the power of Rust, and seen it skillfully wielded by experts to do great things. This talk will wrap things up by outlining the next steps for bringing Rust to your favorite tech communities. We’ll cover the best resources for building expertise at Rust, for you or those you mentor.
Emily Dunham
https://twitter.com/qedunham
https://github.com/edunham
https://users.rust-lang.org/users/edunham/activity
A
So
hi
there
I'm
Emily
Dunham
I'm
the
DevOps
engineer
for
Mozilla
research,
so
I
get
to
hack
on
rest
infrastructure
a
bit
I
got
into
the
project
since
just
before
1.0
came
out
in
2015
I,
mostly
actually
write
Python
for
my
day
job
but
I
play
with
rust.
Organize
arrest,
meet
up
and
teach
introductory
rest
workshops
at
conferences
here
and
there
I'm
going
to
talk
about
a
lot
of
different
things.
Today,
I'll
do
my
best
to
speak
slowly
and
clearly,
but
I
sometimes
use
long
sentences
when
I
get
excited
about
something.
A
So
I'm
from
Portland
Oregon-
and
this
is
my
first
visit
to
Kiev,
where
I'm
from
we
only
know
about
the
past
200
years
or
so
of
history,
so
I
find
it
amazing
to
visit
here,
because
people
know
what
happened.
Hundreds
and
even
thousands
of
years
ago,
right
in
this
place,
visiting
buildings
that
are
almost
a
thousand
years
old,
makes
me
think
about
just
how
new
computers
are
I'm,
going
to
start
with
a
bit
of
an
origin
story,
then
get
on
with
the
fun
and
argumentative
parts
about
rest.
A
That
beautiful
machine
is
an
IBM,
7090
computer.
It
took
up
a
whole
room
and
it
was
state-of-the-art
when
it
came
out
in
1960.
It
costs
2.9
million
dollars
u.s.
at
the
time,
which
is
a
lot
more
now.
It
could
perform
a
hundred
thousand
floating
off
floating-point
operations
per
second,
we
call
those
floating-point
operations
per
second
flops,
so
does
that
sound
fast,
pretty
fast?
Well,
a
first
generation
Raspberry
Pi
the
little
thing
that
everybody
builds
their
toy
projects
with
these
days
was
over
40
times
faster.
So
we
have
a
museum-quality
computer
right
there.
A
How
did
things
get
better?
You
can
improve
a
programmed
performance
either
by
changing
the
hardware.
You
run
it
on
or
by
changing
the
software
for
a
long
time.
We
just
basically
change
the
hardware
to
make
computers
better
by
stuffing
more
transistors
onto
a
chip
and
running
instructions
through
the
system
more
quickly.
We
build
bigger,
faster
computers
and,
as
they
get
cheaper,
we
can
throw
more
of
them
at
a
given
problem.
A
A
However,
there's
a
few
problems
with
this.
First,
the
laws
of
physics
say
that,
eventually,
you
can't
make
a
component
any
smaller
than
a
certain
size.
It
also
gets
more
expensive
to
build
smaller
chips,
as
you
get
close
to
those
limits,
but
customers,
the
people
who
use
and
buy
the
computers
and
keep
the
computer
manufacturers
in
business.
Don't
care
programmers,
keep
writing
bigger
and
more
complex
programs,
and
as
long
as
the
new
computers
are
speeding
up
more
rapidly
than
your
software
is
growing,
things
seem
to
be
improving.
A
When
a
program
needs
a
bigger
and
newer
computer
to
run
it,
what
happens
to
the
old
one?
Well,
it
might
get
handed
down
to
someone
else
or
resold
or
it
might
get
thrown
out,
and
this
is
not
great
for
the
planet
plus
heaven
code
only
works
well
on
the
newest
devices
is
not
great
for
people
who
can't
afford
that
state
of
the
art.
A
Additionally,
if
you're
a
business,
you
have
a
problem,
because
you
have
to
get
your
code
or
website
to
work
on
whatever
people
are
using,
rather
than
what
you
wish
they
were
using.
So
if
your
program
is
too
slow,
they
might
not
be
your
customers
for
very
long,
so
people
want
their
computers
to
keep
getting
better,
but
just
making
the
hardware
faster
is
not
nearly
enough
anymore
and
throwing
more
hardware
at
a
problem
can
get
very
expensive.
A
Hardware,
engineers
are
still
trying
to
fit
more
parts
in
the
same
space,
but
it's
getting
slower
and
more
expensive
to
as
they
get
closer
to
the
limits
of
what
physics
allows,
as
well
as
changing
the
hardware.
We
have
to
change
the
software
cloud
cloud
architectures.
Let
us
run
out
code
on
a
bunch
of
computers
at
once
and
pretend
that
it's
one
big
computer,
but
we
still
want
the
whole
system
to
be
fast
systems.
Programming
languages
are
great
at
letting
you
turn
time
and
effort
into
faster
code
instead
of
just
saying
well
buy
more
computers.
A
However,
systems
languages
tend
to
be
challenging
to
learn.
You
have
to
tell
the
Machine
exactly
what
you
want
it
to
do,
so
it's
easier
to
tell
it
to
do
the
wrong
thing.
Historically,
this
problem
has
been
addressed
by
telling
the
programmer
some
rules
to
follow
and
then
blaming
them
when
they
inevitably
break
those
rules.
As
the
system
gets
more
complex,
there
have
been
other
languages
with
similar
safety
rules
to
rust.
In
fact,
there,
where
we
learned
a
lot
of
our
tricks,
but
those
languages
have
historically
been
very
slow
and
often
difficult
to
use.
A
So
a
whole
bunch
of
people
contribute
to
rest.
Anyone
who
wants
to
make
a
change
to
rest
can
follow
the
contributing
guide.
It
does
say
where
you
should
submit
your
patch
to
many
is
just
around
here
and
they
can
see
if
their
idea
will
work
and
new
people
are
joining
all
the
time.
This
graph
shows
the
total
number
of
unique
contributors
and
by
email
address
at
the
start
of
each
year
and
also
this
weekend,
so
we're
about
a
quarter
of
the
way
into
a
year
about
a
quarter
of
the
new
contributors.
A
We
might
expect
so
note
that
when
I
show
you
graphs
about
contributors
in
the
talk,
I've
counted
people
as
one
email
address
as
one
person,
this
isn't
perfectly
right,
but
it's
about
as
close
an
approximation
as
I
can
get
without
going
into
some
major
identity
and
tracking
who's
who
complicated
issues
so
we've
also
been
growing
in
terms
of
code
base.
Size
rust
has
a
lot
of
people
writing
a
lot
of
code.
This
shows
how
we've
steadily
been
making
more
code
for
as
long
as
rust.
How
to
get
repo
note.
A
The
rate
of
new
commits
per
year
is
pretty
steady.
Rest
11.0
came
out
on
May
15th
2015,
but
we
don't
see
a
drop
in
contributions
after
that
milestone,
new
features
and
bugs
keep
hitting
rests
nightly
channel
every
day.
Bug
fixes
and
backwards-compatible
features
trickle
into
the
beta
and
stable
branches
to
be
released
every
six
weeks
and
as
well
as
individuals,
rest
is,
has
a
growing
fan
base
of
corporations.
There
were
about
63
companies
that
publicly
share
that
they
depend
on
rest.
A
When
I
took
the
screenshot
of
the
friends
page
yesterday,
I
think
our
adopters
represent
an
impressively
diverse
selection
of
the
tech
community.
Rest
is
used
at
companies
ranging
from
brand-new
startups
to
those
that
are
household
names.
Plenty
of
people
who
don't
even
know
that
rest
exists
are
indirectly
benefiting
from
it
if
they
use
software
from
users
like
Mozilla
and
Coursera
and
Dropbox,
and
as
Ashley
mentioned
in
her
talk
before
lunch
rest,
people
are
pretty
well
known
for
liking.
A
To
talk
about
rest
later
I'll
get
into
more
details
of
how
I
think
you
can
succeed
at
promoting
rest,
but
first
I'd
like
to
share
a
tip
for
the
first
time.
You
talk
to
a
potential
new
restoration,
so
pop
quiz.
What's
the
first
thing
you
should
tell
to
someone
who
isn't
sure
if
rust
is
right
for
them
now
we
take
half
an
hour
if
I
had
everyone
shout
something
out
so
I'll
tell
you
that
that
was
a
trick
question
you
shouldn't
start
by
telling
them
anything.
You
should
start
by
asking
questions.
A
A
They
do
have
that
LLVM
support,
it's
a
manageable
amount
of
work
to
get
rest
running
on
it
if
it's
not
already
supported,
but
if
that's
not
there,
yet
they
might
be
better
off
waiting
a
bit
until
it
is,
and
how
would
they
go
about
bringing
rest
in
we've
got
a
lot
of
options
as
you've
heard
about
through
the
day.
Maybe
they
rewrite
a
component,
maybe
they
use
SFI
foreign
function
interface,
perhaps
with
some
help
from
the
bind
gen
tooling
to
bring
it
in.
A
Maybe
they
use
the
corrode
tool
to
translate
C
code
directly
into
unsafe
rust
and
then
iterate
it
from
there
so
think
about
what
adding
or
switching
to
rust
would
look
like
before
you
just
tell
them
go.
Do
this
thing?
Additionally,
there
are
some
less
technical,
but
probably
more
important
components
to
whether
rust
is
going
to
be
a
real
hit
with
a
team.
One
of
the
couple
of
the
big
ones
are:
do
they
have
time
right
now?
A
If
you
have
a
team,
that's
super
great
at
Java
and
they're
halfway
through
building
this
Java
app
that
needs
to
be
released
next
week.
This
is
a
terrible
time
for
them
to
switch
to
rust
and
are
they
interested
if
you're
dealing
with
a
culture
is,
it
would
just
conflict
with
restorations
where
they
wouldn't
get
along
with
the
way
that
we
ask
people
to
ask
questions
or
they
don't
want
to
work
with
an
open-source
tool,
adding
rust
or
attempting
to
address
dental
a
mix
may
cause
more
problems
than
it
solves.
A
So
then
also
a
situation
where
sometimes
somebody
will
have
a
problem
that
looks
to
you
like
rust
is
obviously
the
answer,
but
they
just
think
it's
not
that
great.
So
why
would
somebody
think
that
rest
is
uncool
well,
for
one
thing,
safety
sounds
really
boring,
so
hear
me
out
here.
If
you
were
lost,
you
can
turn
that
tune
back
in
here,
I'm
going
to
have
a
little
bit
of
a
fun
little
rant.
So
this
wouldn't
be
a
proper
keynote
in
my
opinion,
or
I
wouldn't
feel
like
I'd
really
give
in
a
keynote.
A
So
firefighters
seem
cool
for
showing
up
to
dangerous
situations
behind
the
scenes
back
at
the
department.
All
of
your
training
is
about
how
to
promote
safety
and
how
to
avoid
getting
harmed
in
the
line
of
duty.
But
that's
not
how
the
world
sees
you
I
brought
firefighting
interest
as
an
example
of
how
just
doing
the
safe
thing.
All
the
time
sounds
a
lot
less
boring
and
a
lot
less
prestigious
than
taking
risks.
A
Even
today,
a
lot
of
the
cool
new
things
that
we
get
in
the
physical
world
require
a
lot
of
risk
to
get
to
them.
We're
getting
better
at
turning
human
risk
into
risk
for
other
systems,
for
example
the
Curiosity
rover,
terrible
accidents
and
we'll
be
stuck
on
Mars
for
the
rest
of
its
life,
all
to
bring
us
a
bunch
of
new
data.
That's
the
opposite
of
staying
safe.
A
A
One
of
the
first
things
you'll
see
when
you
start
reading
blogs
or
watching
talks
by
people
who
build
new
technologies.
Is
this
advice
to
fail
fast?
It
sounds
like
pretty
good
advice.
Just
like
a
lost
item
is
often
in
the
last
place
you
look,
the
best
solution
is
or
the
solution
you're
looking
for
is
often
the
last
one
you
try.
So
the
quicker
you
try,
a
bunch
of
solutions.
The
sooner
you'll
find
the
one
you
want
right,
so
taking
risks
and
failing
fast,
look
like
the
path
to
success.
A
A
See
you
all
giving
me
this
look
right
now,
this
owl,
the
symbol
of
wisdom,
is
looking
at
me
like
he
thinks
I'm
being
very
unwise.
Indeed,
now
you
as
people
who
think
that
rest
is
also
made
us
to
spend
your
Sunday
at
a
conference
about
it
might
already
know
that
there
are
different
kinds
of
risks
that
software
can
take.
A
You
might
think
and
I
hope
you
think
that
boring
and
predictable
code
is
wonderful,
but
you
haven't
always
known
and
believed
that
if
you
find
yourself
trying
to
sell
rest
to
someone
who
just
doesn't
think
that
safety
is
valuable
right
now,
it's
okay
to
politely,
disagree
with
them
and
it's
okay
to
walk
away
and
to
come
back
once
they
decide
wait.
A
minute.
I'd
rather
have
less
fun
adventures
at
2:00
in
the
morning
when
production
falls
over
so
rust
is
not
the
right
tool
for
everybody.
A
A
Different
users
do
have
totally
different
needs
and
totally
different
requirements
from
a
language.
Maybe
there's
somebody
who
thinks
it
would
be
best
to
pick
a
brand-new
totally
bleeding-edge
tool,
so
they
can
learn
new
things
and
get
the
respect
of
all
their
friends
for
having
been
there
first
or
at
the
other
extreme.
Maybe
they
think
it's
best
to
pick
the
most
oldest,
the
oldest
most
established
tool
that
they
can
find
so
that
they
can
purchase
a
support
contract
and
have
legal
accountability
from
someone.
A
Neither
of
these
use
cases
is
wrong,
but
you
have
to
recognize
that
they
are
very
different
from
one
another,
but
I
would
contend
that
for
anyone
having
safes
code
means
that
you
can
take
the
better
kinds
of
risks.
I
think
that
memory
safety
will
improve
any
systems
programming
project,
but
my
argument
about
danger
and
progress
and
the
glamor
of
taking
risks
was
not
entirely
a
joke
if
you
were
lost,
come
on
back
I'm
less
on
the
sidetrack
now.
A
The
first
big
risk
that
any
restoration
takes
is
to
put
in
the
time
to
learn
the
language
you
could
have
put
that
time
into
another
language.
You
could
have
gone
and
learned
a
sport
or
a
musical
instrument,
or
spent
more
time
with
your
family
in
the
time
that
you've
spent,
studying
rust
or
even
coming
to
this
conference
today,
and
there's
always
a
chance
that
you
might
have
liked
that
more.
A
A
So,
are
you
running
a
rest
project
or
bringing
rest
into
an
organization
you
might
have
been
amazed
and
jealous
when
you
heard
the
stories
about
having
too
many
new
contributors
having
the
rest
code
just
run
too
fast
and
cause
problems?
If
your
code
is
open
and
you've
got
a
bunch
of
easy
bugs,
but
none
of
those
metaphorical,
piranhas
snapping
them
up.
You
can
try
filing
those
easy
bugs
on
an
issue
aggregator
site
to
get
them
some
more
visibility.
A
A
So
now
we've
talked
about
growth
and
we've
talked
about
safety
and
danger
and
taking
better
risks
before
I
hand.
Things
back
to
the
team
I'd
like
to
make
sure
that
everybody
has
the
resources
available
to
succeed
in
the
rest
ecosystem.
If
you've
been
here
a
while
look
at
this
as
a
refresher
in
the
cool
stuff
that
newcomers
don't
necessarily
know
about
that,
you
can
share
with
them
when
they
ask
you
questions
first
off
rest
projects,
cultures
tend
to
look
a
lot
like
the
culture
of
the
compilers
development.
A
All
of
rusts
development
is
done
in
the
open
from
the
forums
and
IRC
conversations
to
the
request
for
comment
process.
It's
easy
for
projects
using
rest
to
see
how
the
compiler
does
its
business.
If
you've
gotten
involved
with
these
open
conversations,
you
might
have
noticed
that
we
used
discourse
forums
instead
of
mailing
lists
for
general
discussion.
We
chose
forums
not
only
to
make
moderation
easier,
but
also
to
make
simultaneous
conversations
easier
to
follow
and
to
find
information
in
later.
A
So
I
think
that
good
practices
practices
that
people
like
trickle
down
into
the
project
that
use
the
compiler
people
get
familiar
with
the
developers
workflows
and
then
they
cherry-pick
the
bits
that
they're
fond
of
and
bring
it
back
to
their
own
work.
This
is
especially
easy
with
rust,
because,
in
addition
to
the
open
communication,
we
focus
on
using
open
tools,
the
bots
that
you
see
helping
out
around
the
rest
community
like
hi-5
and
homo
and
documents
like
the
Code
of
Conduct,
are
openly
licensed.
A
So
one
popular
practice
of
rust
is
adopting
a
policy
that
people
should
communicate
constructively
and
generally
not
be
jerks.
We
call
these
the
codes
of
conduct
and
I
think
that
they
work
in
rust
and
it's
derivative
communities
for
two
really
big
reasons.
First,
we've
had
them
since
the
beginning
and
project
pinned
to
clarify
their
expectations
about
conduct
right
when
they're
starting
out.
This
is
important,
because
if
a
potential
contributor
thinks
that
the
conduct
expectations
are
unfair
or
not
something
they
want
to
abide
by,
they
just
don't
get
started
with
the
project.
A
So
we
end
up
with
a
group
of
only
people
who
think
that
it's
either
ok
or
awesome
to
behave
this
way,
and
second,
we
have
an
amazing
moderation
team
to
make
sure
that
the
codes
are
fairly
enforced.
Saying
we'd,
like
people
to
be
constructive
without
any
enforcement,
is
like
saying
I'd
like
my
code
to
be
faster
without
actually
refactoring
or
optimizing
it.
A
The
second
practice
that
russ
projects,
often
inherit
from
the
compiler,
is
to
have
a
good
test
suite
that
runs
before
the
code
lands
graden.
The
inventor
of
rest
calls
it
the
not
rocket
science
rule
of
software
engineering,
Grayden
news
bot
named
monotone
and
boris
to
enforce
this
rule,
which
is
why
the
bots
account
that
rest
uses
keeps
the
name
boards
to
this
day.
A
The
not
rocket
science
rule
states
that
you
should
automatically
maintain
a
repository
of
code
that
always
passes
all
the
tests
in
rust
and
servo.
The
robot
that
does
this
is
called
homem
once
the
human
says
that
they
want
the
code
to
land
and
a
human
says
they
want
the
code
to
land
by
commenting
our
plus
homo
runs
the
tests
and
then
only
lends
that
code
into
the
master
branch.
If
the
tests
pass.
A
Not
only
does
this
policy
keep
the
master
branch
of
the
repo
in
a
good
State,
it
makes
code
review
a
lot
easier
instead
of
forcing
a
maintainer
to
say
no
to
code
that
fails,
the
tests
we
use
a
robot.
This
shifts
the
dialogue
from
that
maintainer
is
mean
and
wouldn't
land
my
code
to
that
robot
sure
is
picky,
but
the
maintainer
was
able
to
help
me
get
the
code
through
and
no
discussion
of
the
things
that
people
enjoy
about
rest
would
be
complete
without
mentioning
cargo.
A
The
package
manager
makes
it
easy
to
publish
for
others
to
use,
so
cargo
was
partially
motivated,
as
others
have
mentioned
today,
by
frustration
with
the
way
the
other
package
managers
behave
and
it's
a
real
hit.
However,
the
ease
of
publishing
crates
introduces
some
challenges.
Everyone
who
re-implement
the
popular
library
as
a
learning
project
gets
the
publishing.
This
means
that
there
are
often
many
crates
for
similar
purposes
and
it's
not
always
clear
how
they're
different
or
which
one
you
should
use.
A
So
an
ongoing
challenge
for
rest
accessibility
is
for
people
to
be
able
to
find
which
of
the
similar
crates.
They
actually
want.
Categories
have
recently
been
added
to
create
Co.
You
can
see
the
popular
categories
list
there,
although
it
turned
out
to
be
a
bit
of
a
small
font
and
they
make
it
easier
to
compare
the
various
crates
that
do
similar
things.
A
Another
good
way
to
guess
what
crate
to
start
with
is
to
just
take
a
look
at
what
your
favourite
projects
are
using
for
a
given
task
and
if
you're
still
stuck
you're,
always
welcome
to
ask
any
question
on
the
user's
rest,
langa
org
forum
or
on
IRC
you'll,
get
the
best
answer.
Of
course,
if
you
clearly
explain
what
you're
trying
to
do
and
what
options
you've
already
considered
so
publishing
crates
is
one
of
the
most
visible
ways
that
rescue
tzer's
contribute
back
into
a
project's
ecosystem.
A
When
you
publish
a
crate
for
others
to
use,
it's
rarely
very
much
work
to
include
some
basic
documentation
start
with
making
sure
you
have
a
readme
that
describes
what
your
code
is
supposed
to
do
and
what
it
actually
does.
How
close
to
your
goal,
you
are
and
make
sure
to
add
a
contributing
file
to
tell
people
who
might
want
to
help
how
they
should.
If
that
contributing
file
says,
this
is
a
side
project
I,
don't
particularly
want
to
deal
with
it,
because
I'm
done.
Please
use
that
other
crate.
A
A
Many
organizations
and
projects
aren't
allowed
to
use
unlicensed
code
because
often
local
laws
say
that
code
without
a
license.
That
frees
it
up
is
copyright
of
its
original
author
and
no
one
else
is
allowed
to
do
anything
that
copies
it
so
be
kind
to
people
in
those
jurisdictions.
Even
if
you
are
not
in
one
by
making
sure
that
you
clarify
what
you
intended
by
sharing
that
code
and
rust,
incredibly
vibrant
international
community
exists
in
person
as
well
as
online,
so
this
community
is
built
by
the
people
who
organize
and
attend
as
many
meetups
and
conferences.
A
Yes,
that's
you
so
new
restorations
who
want
to
make
friends
and
ask
questions,
should
check
if
there's
a
rest
meet
up
near
them.
You
can
also
start
a
meetup
or
help
someone
start
a
meetup
if
they
haven't
got
one.
Yet.
Oh
that's
enough
of
the
globe.
You
can
imagine
that
the
first
cluster
is
in
North
America.
The
other
clusters
in
Europe
we've
got
various
points,
all
the
way
down
the
east
side
of
Asia,
some
in
India,
some
in
Australia
and
New
Zealand,
and
some
on
the
east
side
of
South
America.
A
So
another
important
way
that
restorations
get
involved
in
the
ecosystem
is
to
provide
ideas
and
feedback
on
the
languages
direction.
The
language
is
shaped
by
user
contributions
through
the
RFC
process,
as
well
as
through
bug,
fixes
and
other
code.
It's
described
in
more
detail
in
the
contributing
guide.
A
If
you
haven't
read
through
already
and
remember
that
you
can
always
no
matter
who
you
are,
you
can
always
suggest
the
change,
but
changes
will
be
scrutinized
to
make
sure
that
they
won't
break
things
for
other
people
who
the
volunteers
all
over
the
world,
making
up
rusts
9
official
teams.
Each
team
has
a
mailing
list
where
you
can
direct
quest
about
their
area
of
expertise,
and
most
teams
have
an
IRC
channel
as
well.
A
You
can
ask
on
users,
dot,
rest
langa,
org
or
if
neither
of
those
work
you
can
shoot
an
email
to
the
community
team
asking
where
you
should
find
the
answer
to
your
question,
the
more
you
tell
us
about
what
you're
trying
to
do,
what
you've
tried
and
what
happened
instead,
of
course,
the
better
we
can
help
you,
so
the
community
team
also
has
a
site
where
you
might
be
able
to
find
the
answer
to
your
question
before
we
ask
it.
We
aggregate
all
kinds
of
resources
about
getting
involved
with
rust
and
the
various
rest
projects.
A
So
if
you
notice
something
missing
from
the
community,
RS
slash
resources
page,
please
help
us
add
it
submit
a
PR
or
an
issue.
Saying
there's
this
cool
thing:
you
don't
have
yet
so
this
whole
community
thing
who's
actually
building
rust
like
is
it?
Is
it
a
Mozilla
project?
I
know
Mozilla
funds
it
a
lot.
Well.
A
Community
is
basically
the
entirety
of
the
project,
while
Mozilla
sponsors
compiler
development
by
employing
some
full-time
staff.
Almost
all
contributors
are
from
outside
of
Mozilla.
If
we
guess
the
contributors
email
address
represents
where
they
work.
There
is
some
error,
because
a
few
Mozilla
ins
might
use
a
personal
address.
There's
also
some
error,
because
some
people
at
Mozilla
who
aren't
paid
to
work
on
rest
might
use
their
work
address.
This
pie
chart
speaks
for
itself,
the
whole
rest,
compiler
repo
has
39
unique
contributors
using
email
addresses
at
Mozilla,
calm
and
2033
contributors
from
other
places.
A
So
that's
cool.
Maybe
we
just
get
a
bunch
of
drive-bys
if
you
break
it
down
by
who
wrote
the
commits.
Instead,
you
see
about
the
same
story:
less
than
a
quarter
of
the
commits
come
from
people
who
might
be
working
on
a
full-time
as
well.
Technical
progress
as
well
as
its
online
popularity,
is
driven
by
you,
the
community.
A
So
you
probably
already
liked
rest
since
you're
at
this
conference.
I
hope
that
stepping
back
to
look
at
why
we've
got
rest
and
where
what
get
from
it
has
been
enjoyable
or
educational
as
a
way
to
wrap
up.
If
you
did
get
lost
tune
back
in
because
I'm
about
to
recap,
the
three
key
points
from
those
sections,
so
the
one
of
the
most
important
takeaways
is
that
rust
is
growing
up
and
rest
is
ready
for
and
used
in
production.
A
So,
first,
you
need
to
demand
that
your
computer
do
everything
it
can,
when
throwing
more
machines
at
it
or
running
things
on
a
faster
machine,
won't
cut
it
anymore.
It's
time
for
a
systems.
Language
and
rest
is
an
excellent
choice,
so
use
the
tools
available
or
build
new
ones
to
improve
your
codes
performance
next
share.