►
Description
RustConf 2019 - Bringing Rust Home to Meet the Parents by Jeremy Fitzhardinge
How can you bring your love for Rust to your organization, and how can you set it up for success?
Facebook has a ton of code written in a lot of languages. Is there room for Rust? Yes! This talk covers my journey of discovery integrating Rust into a large existing software ecosystem while trying to preserve all of Rust’s nice properties. Writing, building, testing, third-party code, foreign bindings, debugging, deployment, monitoring all need to be re-examined in the light of this new environment. How did we go from nothing to a core production service in Rust?
No two orgs are alike - you’ll walk away with a practical set of questions you’ll need to consider for your org (and maybe some answers).
A
Hello,
so
we've
all
been
using
rust
for
some
amount
of
time,
I've
been
using
it
since
before
1.0,
and
for
a
long
time
it
was
a
fun
sort
of
side
experiment.
But
what
have
you
wanted
to
make
it
part
of
your
everyday
life?
One
if
you
wanted
to
bring
it
to
work
and
make
it
the
focus
of
your
working
day,
so
hello,
I'm,
Jeremy
I've,
been
in
the
industry
for
about
thirty
years,
mostly
doing
system
software
and
like
at
the
kernel
level
below
the
kernel.
A
Just
above
the
kernel
mostly
see
mostly
C++
a
bit
of
C++,
but
basically
I've
seen
everything
that
can
go
wrong
in
a
C
program
which,
as
it's
commonly
known,
is
a
lot
of
things.
So
when
I
found
rust
and
I'm
also
appeal
kind
of
enthusiast
and
so
I've
been
experimenting
with
a
lot
of
languages,
but
when
I
found
rust,
it
was
the
first
programming
language
that
I
that
genuinely
solved
a
whole
class
of
problems,
but
also
could
replace
C
in
every
possible
role.
A
That
C
currently
has
so
I
was
super
enthusiastic
about
it
and
started
using
it
everywhere.
Three
years
ago
I
joined
Facebook.
It
was
the
first
time
I
had
deliberately
joined
a
large
company,
and
so
it
was
an
interesting
experience
for
me
to
learn
how
large
companies
work,
how
things
fit
together,
how
technologies
are
used
in
large
companies
I
found
that
there
was
a
lot
of
interest
in
rust,
but
no
one
really
doing
anything
about
it
was
just
sort
of
an
ambient
enthusiasm.
So
I
thought
why
not
do
something
about
this?
A
A
Enthusiasts
and
they'll
be
enthusiastic
about
anything
they're
enthusiastic
about,
but
a
lot
of
people
at
a
job
they're
to
work
and
they've
got
a
thing
to
do,
and
they
have
managers
and
performance
bonuses
and
data
that
are
all
kind
of
attached
to
being
able
to
do
that
thing,
and
so
it's
a
risk
for
them
to
choose
rust.
There
has
to
be
a
good
reason
for
them
to
do
so,
and
so
rust
doesn't
have
to
be
just
a
bit
better
than
something
else.
A
A
A
The
argument
I'm
going
for
that
I
think
holds
pretty
well.
Is
that
rust,
detects
large
classes
of
serious
bugs
at
compile
time
and
that
detecting
bugs
at
compile
time
is
orders
of
magnitude
cheaper
than
running
finding
those
bugs
when
the
code
has
gone
into
production
when
it's
crashing
in
a
bad
way.
A
A
So
when
I
joined
I
was
in
the
source,
control
team
and
the
source
control
team
had
this
problem
that
they
could
see
a
whole
bunch
of
curves
going
mm-hmm,
and
they
could
see
at
some
point
that
the
source
control
team,
like
primarily
the
tooling,
is
based
around
material
which
is
written
in
Python,
and
they
had
spent
many
years
very
thoroughly
tuning
that
that
code
base.
So
it
was
actually
doing
a
reasonably
good,
a
surprisingly
good
job,
given
the
scale
that
it
was
operating
at.
A
But
they
could
see
that
there
was
a
maximum
limit
at
which
mercurial
could
accept
commits,
which
was
one
of
the
sort
of
primary
concerns,
and
they
could
see
that
the
curves
were
going
to
hit
that
rate
within
a
couple
of
years.
So
there
was
gonna,
be
a
hard
ceiling,
and
you
know
one
off.
One
possibility
would
have
been
to
just
try
and
optimize
mercurial
a
bit
more
rewrite
bits
of
it
in
other
languages
hack
around,
but
there
was
also
a
whole
bunch
of
functional
things
that
mercurial's
model
wasn't
really
accommodating.
A
So
this
plan
was
already
formed
when
I
joined
the
company
and
it
was
sort
of
sitting
on
the
Shelf
waiting
for
someone
to
adopt
it,
and
it
was
basically
new
source
control
server
written
in
a
compiled
language,
no
compiled
language
in
facebook
terms.
That's
really
a
code
for
C++,
but
I
kind
of
was
new
to
the
company,
and
so
I
could
like
happily
ignore
that
and
go
well
compiled
like
rust
as
a
compact.
A
Let's
do
it
and
rest,
and
the
case
I
made
then
was
that
a
source
control
server
correctness
is
a
very
is
like
the
primary
requirement.
Like
obviously,
we
had
performance
goals,
but
we
were
pretty
confident
we
could
hit
those
regardless
just
by
writing
into
compiled
language.
But
correctness
was
very
important
that
corrupting
source
code,
which
is
literally
the
crown
jewels
of
the
company,
is
a
complete
non-starter.
A
So
we
started
Mononoke
and
also
made
the
decision
at
that
point
to
make
it
an
async
thing,
and
that
was
a
super
early
adopter
of
Tokyo
and
rust
async,
because
I
started
the
project
I
committed
the
first
file
for
it
on
the
day
that
Tokyo
hit
crates
I/o,
and
that
was
just
coincidence.
I
was
going
to
vendor
it
from
get,
but
it
hit
Cate,
say
oh,
and
so
that
made
it
easier
to
do,
but
don't
even
get
started.
I
had
to
do
a
bit
of
groundwork.
A
I
had
to
make
a
few
targeted,
but
high
quality
integrations
into
the
environment.
I'm
going
to
go
into
a
bit
more
detail
about
this,
but
I
had
to
integrate
rust
into
the
build
system,
integrate
it
into
the
test
environment
and
integrate
it
working
on
a
way
of
handling
third-party
dependencies
with
crates
layer.
A
So,
three
years
later,
Mononoke
is
now
in
production.
It's
the
source
of
truth
of
one
of
our
largest
highest
through
foot
repos,
and
it's
been
working
pretty
well
and
all
of
the
rust
claims
checked
out.
We
basically
spent
no
time
debugging,
weird
memory,
corruption
and
strange
race
conditions
and
stuff
like
that,
and
a
lot
of
the
people
who
sort
of
watched
the
project
and
then
sort
of
looked
at
the
retrospective
and
thought
and
and
observed
that
compared
to
a
C++
program
in
which
that
would
have
been
the
normal
last
few
months
of
going
into
production.
A
Kind
of
interesting
sources-
one
of
them
is
stack
overflows.
One
of
them
is
just
unhandled,
C++
exceptions,
Crossing
the
FFI
boundary
and
so,
and
the
rest
are
just
buggy
C++
code
and
there
isn't
too
much
of
that.
To
be
honest,
but
the
stack
overflow
is
one
was
the
kind
of
the
most
interesting
from
my
point
of
view,
and
so
that
was
a
successful
enough
project
that
the
rest
of
the
source
control
team
has
adopted.
A
Alright,
so
what
is
the
environment
that
I'm
talking
about
here
like
what
does?
What
does
a
facebook
codebase?
Look
like
and
I'm
specifically
talking
here
about
back-end
code
bases
like
where
else
sort
of
back-end
services
live
that
are
not
directly
visible
to
the
front
side
of
either
your
apps
or
your
the
website?
The
primary
languages
in
there
are
C++,
Java
and
Python,
like
most
of
the
back-end
services,
are
written
in
C++.
A
A
lot
of
the
kind
of
analysis
stuff
is
in
Java
and
there's
tons
of
Python
just
gluing
things
together,
but
those
are
the
three
main
languages.
It's
a
highly
highly
polyglot
code
base.
There
are
lots
and
lots
of
languages
in
use
in
general,
teams
have
a
lot
of
freedom
to
choose
what
technologies
and
what
languages
they
wish
to
use
and
answer
they
do,
and
so
we
have
Oh
camel
and
Haskell
and
R
and
even
bits
of
D
in
there.
A
But
normally
when
teams
choose
a
language,
they
have
a
very
good
reason
to
do
so.
They're
very
pragmatic,
like
they
can
choose
whatever
they
want
and
someone's
going
to
come
along
and
say.
Are
you?
Surely
you
wanted
to
use,
say
brain-fuck
for
this
project
like
it's
got
a
really
good
debugging
environment
say
it's
a
huge
codebase.
We
have
a
single
great
big
mono
repo
that
well,
we
have
multiple
mono
repos.
A
We
like
them
a
lot,
but
we
are
hoping
to
get
it
to
be
one
mono
repo
eventually,
but
it's
got
millions
of
files
in
it,
hundreds
of
millions
of
lines
of
code,
all
just
scattered
across
many
many
directories,
and
we
have
a
sort
of
general
tooling
goal
like
we
have
like
it.
Obviously,
that
is
just
not
going
to
work.
If
you
made
a
regular
git
repo
of
that
size,
checked
it
out,
tried
to
Rumble
around
and
use
that
it
wouldn't
work.
A
So
we
spend
a
lot
of
investment
on
tooling
with
a
general
goal
that
the
amount
of
time
you
spend
waiting
for
things
to
happen
should
be
proportional
to
the
size
of
your
project,
not
to
the
size
of
the
entire
repo
and
as
the
repo
grows.
If
your
project
stays
the
same
size,
it
should
still
take
about
the
same
time
to
get
things
done.
A
One
of
the
important
tools
in
there
is
bucked
the
build
system
which
builds
a
dependency
graph
across
the
entire
source
base,
and
so,
when
you
say
build
this
specific
target,
it
knows
how
to
build
that
target
and
all
its
dependencies,
no
matter
what
language
they're
in
so
and
then
there's
a
whole
bunch
of
production
side
stuff
as
well
to
monitor
things
and
deploy
them.
And
so,
by
contrast,
let's
look
at
the
the
rest
view
of
the
world
like
as
a
way
of
getting
to
how
does
rust
fit
into
all
of
this.
A
So
I
think
an
ambiguous
lis.
The
first
rule
of
rust
is
safety.
If,
like
safety,
is
a
foundation
of
everything
else
without
safety,
nothing,
nothing
else
is
really
worth
talking
about,
but
it's
a
new
language.
So
there's
a
lot
of
scope
for
experimentation.
Greenfield
development.
There's
no
reason
why
rust
has
to
do
things
the
same
way
that
everything
else
does
it's
worth
experimenting
that's
offset
by
having
a
core
stability.
A
There's
the
stability
guarantees
of
the
language
that
allow
continuous
evolution
while
not
breaking
backwards,
compatibility
but
again,
I've,
set
by
crates
I/o,
this
incredibly
vibrant
environment,
with
lots
and
lots
of
third-party
things
in
which
experiments
can
happen,
and
things
can
be
trying
to
and
accepted
and
adopted
widely
or
thrown
away.
If
they
don't
work
out.
A
So
then,
cargo
managers
build
in
dependency
and
it's
one
of
the
things
that
regular.
You
know,
newcomers
to
Rush
regularly
say
cargo
is,
is
one
of
the
brilliant
things
about
the
Rast
ecosystem.
I
could
add
a
new
dependency
really
easily.
You
know
particularly
for
C++
programmers,
it's
a
revelation,
but
for
other
environments,
it's
pretty,
you
know
it's
it's
a
lovely
tool,
and
so,
as
a
result,
cargo
is
kind
of
the
center
of
the
rust
universe.
It's
the
thing
that
binds
the
rust
ecosystem
together
in
a
particular.
A
It's
the
thing
that
gives
you
access
to
crates
IO.
So
in
order
to
have
access
to
this
vibrant
third
party
code,
culture,
you
need
cargo,
but
cargo
is
very
highly
tuned
towards
rust.
It
treats
the
entire
universe
as
rust
and
everything
else,
and
if
the
everything
else
gets
very
short
shrift
and
in
fact
you
could
say
that
supporting
non
rust
is
an
on
goal
for
cargo.
A
So.
The
big
question
is:
how
do
we
retain
rusts
essential
benefits
while
integrating
it
with
this,
this
larger
existing
ecosystem
and
also
get
the
benefits
of
that
that
other
ecosystem,
because
you
know
it's
been
built
that
way
for
specific
reasons,
to
support
some
specific
kinds
of
activities
so
going
back
to
the
rust
10x
advantage,
what
is
the
cost
of
a
bug
to
Facebook?
Well,
if
you
see
a
headline
saying
Facebook
down
for
users
in
X
internally,
what
that
turns
into
is,
you
know,
specifically,
it's
a
lot
of
lost
revenue,
so
you
know.
A
Even
you
know,
an
hour
of
downtime
is
an
ungodly
amount
of
money,
and
so-
and
at
least
some
of
those
those
bugs
root
cause
to
yeah.
We
traced
it
through
and
then
this
program
here
did
a
use
after
free
after
this
diff
and
like
yeah,
this
one
little
innocuous
change
turned
out
to
to
take
out
the
entire
the
entire
site
for
six
hours
or
whatever.
A
So
as
a
result,
it
behooves
Facebook
to
spend
quite
a
lot
of
money
on
improving
code
quality,
and
it
does
this
in
a
number
of
different
dimensions.
One
is
like
code
review
and
static
analysis
and
test
infrastructure,
and
you
know
in
a
lot
of
ways
what
Facebook
does
in
these
areas
is.
Is
world
class
like
and
you
know,
we
spend
a
lot
of
engineering
hours
on
these
kinds
of
activities
and
they're
effective,
like
we
do
see
improvements
when
when
we
spend
more
effort
on
on
these
areas,
the
rate
of
bugs
goes
down
mostly.
A
But
the
trouble
with
all
of
these
things
is
that
they're
kind
of
afterwards
things
so
the
typical
pattern
is
you
write
some
code,
you
bitter
eight,
it
kind
of
does
what
you
think
it
should
do
pass
some
local
tests,
you
get
it
reviewed.
You
commit
that
to
the
repo
goes
into
production,
done,
I'm,
gonna,
go
off
and
think
about
the
next
thing,
and
then
I
mean
even
code
review.
A
Like
is
a
pretty
like
manual
thing,
so
you're
kind
of
relying
for
C++
code
base
you're
relying
on
someone
to
actually
pay
attention
to
every
single
allocation
and
look
at
all
of
the
details
for
static
analysis.
It
can
take
20
minutes,
30
minutes
half
an
hour
and
it's
half
now
an
hour
to
to
come
back
with
the
result,
and
that
may
be
too
late
yucky.
A
A
It's
clearly
ok,
and
so
what
Russ
does
is
by
having
solving
a
learned
class
of
these
problems
depicting
them
at
compile
time
it's
in
your
inner
loop,
it's
while
you're
busy
working
on
the
code
everything's
in
your
head
when
it
pops
up
a
life
time
error
you
go,
oh
I,
see
yeah,
that's
obvious.
Let's
fix
that
up,
and
so
by
the
time
the
code
commit
is
committed.
It's
got
at
least
some
base
level
of
correctness.
A
That
you're
not
to
worry
about
anymore
and-
and
the
nice
thing
about
rust,
is
that
the
executables
themselves
operationally
looked
like
C++
executables
they're
standalone
self-contained
executables,
so
you
can
take
that
and
you
can
drop
those
into
a
production
environment
expecting
C++
and
it
more
or
less
works
the
same
way.
But
we
haven't
opened
challenge
here,
because
the
essence
of
this
argument
is
rust,
souls
bugs
really
early.
So
the
key
question
is:
how
can
you
quantify
the
bugs
that
didn't
happen?
How
can
you
quantify
you
know
this
bug?
A
This
might
have
had
a
bug
this,
this
particular
compilation
had
a
compilation
area
that
had
a
crept
through
would
have
turned
into
a
massive
outage.
It's
very
hard
to
do
that
and
we're
still
kind
of
I'm
still
working
on
like
how
to
quantify
these
things,
because
that
would
really
help
with
coming
up
with
an
argument.
A
Some
of
the
secondary
effects
here
are
that
code
reviews
a
higher
level
I
sort
of
alluded
to
this
earlier,
but
when
you
don't
have
to
worry
about
fine-grained
details
of
lifetimes
and
locking
and
that
sort
of
stuff,
a
reviewer
can
just
look
at
the
code
and
say
well:
if
it
compiles
all
of
that
stuff
is
basically
correct.
Let's
look
at
the
high
level
design.
Is
this
actually
the
right
way
to
fit
this
code
together?
Is
this?
A
Actually,
you
know
the
correct
design
and
you
know
whatever
scale
you
you
want
to
look
at,
but
it
means
that
the
amount
of
reviewer
attention
is
is,
is
much
more
sort
of
intellectually
engaging
and
you
get
higher
quality
reviews
which
you
know,
helps
a
lot.
You
know
it's
in
essence.
Why
is
this
diff
lock?
It
is
rather
than
how
it
works,
though.
Obviously,
how
it
works
is
important,
but
you
don't
have
to
worry
about
the
correctness,
a
spec
to
that
and
there's
also
a
maintenance
improvement.
A
One
of
the
biggest
risks
is
not
the
when
the
code
is
originally
written
because
the
person
who
wrote
it
is
thinking
deeply
about
that
domain.
They
have
everything
in
their
head.
They
have
all
the
context.
They
can
probably
get
that
code
right.
You
know
eventually,
first
time,
you
know
even
in
C++,
but
it's
when
the
same
engineer
comes
back
three
months
later,
six
months
later
to
just
drop
in
one
little
bug
fix-
and
we
saw
this
weird
little
thing:
let's
just
drop
a
fix
in
here
and
without
having
that
complete
context
in
the
head.
A
They
can
say:
oh
I'm,
going
to
put
it
in
here,
not
realizing
that
the
thing
that
they're
doing
the
test
on
for
that
little
one
one-liner
fix
was
actually
freed
five
lines
before,
whereas
in
rust
you
can
just
sort
of
make
those
code
changes
and
they
are
the
compiler
they
don't
and
if
they
do
compile.
You
have
a
much
higher
assurance
that
at
least
the
fix
is
not
going
to
be
desperately
broken.
A
So
who's
actually
using
rest.
We've
we've
had
quite
a
lot
of
people
adopting
rust
within
the
company
as
a
result
of
these
initial
successes
who
are
they?
Well
surprisingly,
it's
been
the
dynamic
language
users
that
by
far
the
most
active,
enthusiastic
early
adopters
of
rust,
where
Python
programmers
they
basically
set
themselves
up
a
game
of
take
my
favorite
plaything
scripts
and
convert
it
to
rest
and
the
resulting
rust
looks
like
a
Python
script.
A
That's
been
converted
into
rust,
it's
not
at
all
idiomatic
or
Kruti,
or
anything
like
that,
but
it
did
compile
and,
as
a
result,
it
probably
works
because
it
looks
exactly
like
the
patient
that
also
probably
worked,
and
so
this
was
a
really
great
educational
opportunity
for
a
large
number
of
engineers
or
relatively
large.
A
large
number
India
is
to
get
familiarity
with
rust
in
you
know
they
here,
burrow,
checker
and
scary
lifetime
stuff
and
that,
but
really
they
got
their
Python
script
working.
It's
not
that
scary
anymore.
A
A
We
have
a
lot
of
command
line
interface
programs,
a
lot
of
them
are
written
in
Python.
Python
is
quite
nice
language
for
writing
those
things,
but
the
result
is
very
unusable
due
to
lots
of
ways
in
which
we
kind
of
deploy
Python.
It
starts
up
very
slowly,
so
it's
quite
common
to
have
a
command-line
interface
that
takes
five
seconds
to
show
a
usage
message.
A
It's
very
unpleasant
and
obviously
the
Python
side
of
things
could
be
fixed,
but
if
you
could
just
sit
down
and
write
a
Russ
program
that
has
a
nice
CLA
that
does
the
thing
you
want
and
starts
up
in
a
millisecond,
then
that's
a
huge
huge
advantage.
So,
given
that
you're
rewriting
Python
code
into
rust
anyway,
why
not
use
it
for
these
interactive
programs
and
rust
has
a
secret
weapon
here
like
Plath
is
a
very
capable
library
and
the
combination
was
struct
up?
Is
just
magical
people
really
love
it?
A
You
can
show
them
your
definer
structure
if
you're
not
familiar
with
struck
ducked,
it's
a
procedural
macro
that
you
apply
to
a
structure
and
that
structure
defines
your
command-line
interface,
and
so
you
can
just
show
someone
here
is
a
structure.
This
structure
represents
the
command-line
interface
and
the
value
of
that
structure
is
the
command
line.
You
actually
got.
You
go.
That's
incredibly
simple.
A
It's
way
ahead
of
any
technology,
that's
well
these
commonly
available
technologies
for
other
languages,
for
doing
that
sort
of
thing
and
yeah,
even
Python,
presumably
could
in
principle,
have
something
similar,
but
I
don't
know
that
that
exists.
So
we
have
all
of
these
new
russ
users
in
the
company.
How
do
we
support
them?
A
Most?
Almost
all
the
teams
that
have
adopted
rest
have
not
actually
had
any
Russ
programmers
on
the
team
at
that
time.
They've
had
people
who
are
enthusiastic
about
rest,
but
very
few
people
who
have
actually
used
it
in
any
kind
of
intensive
way.
So,
as
a
result,
ramp
up
time
has
been
a
big
concern
and
it
turns
out
that
there's
a
kind
of
universal
experience,
which
is
that
it
takes
about
two
to
three
weeks
of
fighting
the
compiler
three
to
five
weeks
of
working
out
how
to
get
things
and
at
about
eight
weeks.
A
That's
quite
dependent
on
the
language
background,
like
people
coming
from
functional
language
backgrounds
have
a
much
better
time
of
it
than
people
coming
from.
Go
and
Java
go
and
java's
sort
of
general
model
of
like
a
great
big,
tangled
heap
of
references
in
a
in
a
garbage
collected
heap
where
everything
can
mutate.
Everything
else
is
a
terrible
starting
place
for
anything
to
do
with
rest.
A
The
big
danger
point
happens
sometime
later,
like
say
within
a
month
or
two
in
which
someone
says
you
know,
I
really
understand,
treats
now
I'm
going
to
use
them
everywhere
and
then
suddenly
you
end
up
with
a
code
base,
that's
full
of
type
parameters
and
type
constraints
and
15
line
wear
blocks,
and
it
takes
maybe
in
the
best
case
a
week
to
realize
that
that
was
a
disastrous
mistake.
This
mistake,
but
sometimes
that
can
last
for
months
and
the
relief
of
just
sort
of
like
collapsing.
All
of
that
complexity
out
is
palpable.
A
We
haven't
actually
needed
very
much
internal
training
materials
so
far,
but
that's
definitely
changing.
Now
that
the
the
user
base
is
changing
mostly
the
people
who've
been
ducting.
Arrests
are
intrinsically
enthusiastic
about
rust,
so
they've
already
found
that
found
everything
for
themselves,
but
we're
moving
into
a
class
of
people
where,
where
that's
not
the
case,
so
we're
having
to
build
a
community
within
the
company
that
is
a
reflection
of
rust
external
community.
A
It
depends
a
lot
on
the
external
community
being
very
vibrant
and
healthy,
and
one
of
the
foundational
principles
of
rust,
as
I
said
before.
A
safety
but
I
see
that
that
extends
into
rusts
community.
That
the
like
psychological
safety
of
being
able
to
jump
in
and
ask
questions
and
not
get
shouted
at
is
an
extremely
important
property
that
I
see
the
Russ
community
trying
to
maintain,
and
so
we
have
the
same.
Yeah
I've
been
explicitly
adopting
the
same
policy
internally
as
well.
A
That
allows
you
to
sort
of
register
yourself
as
someone
who's
who's
good
at
reviewing
rusts
code,
and
you
can
help
out
a
team
review
some
of
their
code.
They
also
encourage
people
to
join
that
if
they're
learning,
because
watching
other
reviews
is
quite
a
useful
learning
experience,
one
of
the
big
things
that
you
had
to
do
is
that
I've
been
emphasizing
is
removing
gratuitous
weirdness.
A
So
we're
getting
to
a
point
now
where
rust
is
not
just
for
the
enthusiasts,
not
just
for
the
fans.
We
need
to
reach
out
to
the
people
who
very
pragmatic.
They
have
a
job
to
get
done.
They
have
many
options
rust
as
one
of
them,
and
it's
not
obvious
to
them.
That
rust
is
the
best
option,
and
maybe
it's
not.
A
The
intrinsic
security
aspect
of
it
is
very
important
for
any
use
case
where
rust
might
be
used
on
untrusted
data
and
kind
of
tied
to
that
is
that,
like
the
learning
curve,
is
really
steep,
which
sounds
like
a
bad
thing,
but
the
thing
about
steep
slopes
is
that
you
end
up
higher,
faster
and
so
newcomers
to
rust.
Once
you've
learned
the
basic
language,
you
could
then
set
them
to
write
security-critical
code
without
really
worrying
about
it
too
much.
You,
like
you,
ordered
it
for
unsay.
A
When
you
look
for
egregiously
wrong
things,
but
you're
then
fairly
confident
that
it
can't
do
anything
very
broken,
whereas
in
C++
you
wouldn't
put
someone
who'd
been
using
the
language
for
three
months
on
a
security,
critical
thing
and
you
know:
there's
trade-offs
there,
but
I
think
it's
an
important
point
and
they
think
is
really
nice.
That's
that's
still
a
strong,
a
strong
point.
I
think
I
mean
interestingly,
every
team
that
has
considered
using
rust
so
far,
and
this
won't
be
true
forever,
but
I
think
it's
true.
A
So
far,
everyone
who's
considered
rust
has
ended
up
using
it
and
everyone
who's
adopted.
It
so
far
has
not
regretted
it.
So
I
see
that
as
basically
strong
reinforcement
for
why
other
teams
should
adopt
it.
So
where
are
we
now?
We
are
in
a
place
where
we
have
a
very
solid
starting
point:
there's
an
active
community
there's
several
critical,
like
teams
working
on
strategically
critical
software
using
rust.
A
Many
of
the
standard
api's
are
available,
so
it's
fairly
easy
to
sit
down
and
write
new
code
and
just
expect
it
to
work
within
facebook's
infrastructure
but
and
the
sort
of
general
development
experience
feels
good
and
generally
people
are
enthusiastic.
There's
a
lot
of
enthusiasm,
but
it's
not
the
default
language
for
any
particular
domain.
Yet,
like
I,
think
that
security
software
ought
to
be
rust
by
default,
but
it's
not
yet.
The
non
enthusiasts
are
beginning
to
pay
attention,
but
we
need
to
make
this
case.
We
need
to
be
convincing
about
it.
A
We
are
making
terrible
use
of
rust,
doc
and
there's
a
bunch
of
other
parts,
the
rust
ecosystem
that
we're
not
really
making
good
use
of
that.
We
need
to
spend
more
effort
on
and
in
general
lots
of
Polish.
There
is
what
what's
there
is
high
quality
and
generally
quite
useful,
but
there's
rough
edges
and
there's
missing
functionality.
As
we
say
in
facebook,
this
journey
is
1%
finished,
but
if
you
want
to
come
and
help
we're
hiring.