►
Description
This is a recording of the Rust Bay Area meetup hosted at Facebook's Headquarters in Menlo Park, CA on August 15th, 2019.
The speakers were:
[0:30] Gregory Szorc (Developer Productivity Engineer at Airbnb) talking about PyOzidizer, a tool for producing standalone Python binaries written in Rust.
[45:21] Jeremy Fitzhardinge (Software Engineer at Facebook) talking about the process of bringing Rust into production at Facebook. This talk is a preview of Jeremy's talk at RustConf 2019.
A
Alright,
hi
again
everybody
so
this
time
it's
for
real,
so
we're
gonna
get
started
with
the
talks.
Now.
Thank
you
again
so
much
for
coming.
We
still
have
a
ton
of
pizza
in
the
back
and
a
ton
of
drinks.
I
have
been
told.
We
are
not
allowed
to
leave
leftover
drinks
in
this
room.
They
have
to
be
dealt
with.
So
please
help
me
deal
with
the
problem
either
during
or
after
this
talk
anyway.
So
our
first
speaker
of
the
evening
is
going
to
be
Greg's.
A
B
If
one
thing
that
wasn't
said
was
I
have
a
bog,
grigory's
or
calm,
which
has
a
lot
of
information,
mostly
about
version
control.
Stuff
I
am
a
core
contributor
to
the
mercurial
version.
Control
tool.
I've
been
doing
that
for
several
years,
really
into
build
systems
and
version
control
and
lots
of
developer,
tooling
things
so
yeah.
What's
actually
before
I
go
into
the
talk,
I'm
curious.
If
there's
anyone
here
who
who
has
heard
of
pie
oxidizer
before
ok?
B
B
Furthermore,
most
people
care
that
software
enables
them
they
care
a
little
about
the
software
itself.
The
the
major
exception
to
this
is
developers,
probably
the
people
in
this
room.
We
care,
or
we
like
to
think
we
care
about
things
like
what
language
software
is
implemented
in,
even
though
the
technical
implementations
usually
just
don't
care
they
don't
they
don't
often
affect
the
underlying
utility
of
a
piece
of
software.
B
However,
lots
of
software
forces
people
to
care
about
the
technical
underpinnings
of
it
most
people.
They
just
want
something
they
can
double-click
on
to
run.
This
is
like
your
parents
or
grandparents,
your
aunt
and
uncle,
who
aren't
just
technically
literate.
They
just
want
to
download
something
from
an
app
store
or
something
like
that
and
click
on
it
to
run.
They
want
an
icon.
B
So
let's
give
some
examples
of
this.
This
is
how
you
would
run
software
on
Mac
OS.
If
you
want
to
use
homebrew,
for
example,
and
to
you
and
me,
if
we
use
Mac's
like
we're
familiar
with
this,
there's
a
package
manager
and
you
install
the
package
manager
and
you
you
know,
run
a
command
to
install
software
sounds
easy
for
us
harder
for
non-technical
illiterate
people
for
Python.
You
may
have
seen
this
this
xkcd,
it's
it's.
B
It's
pretty
bad
in
Python,
it's
this
came
out
several
years
ago
and
I
think
things
are
slightly
better
than
this,
but
Python
is
generally
pretty
bad.
I'd,
say:
ruby
is
also
in
the
same
boat
here
and
not
to
diss
on
the
the
Python
community
or
the
dynamic
language
community.
That
much
rust
has
this
problem
as
well.
How
do
you
install
a
rust
application?
Cargo
install?
What's
Cargo,
it's
a
package
man?
What's
a
package
manager?
What's
rust
people,
they
don't
want
to
deal
with
this.
B
This
is
all
things
that
we
force
people
to
deal
with
to
run.
Software
and
I
ran
into
this
when
I
released,
PI
oxidizer,
it's
a
rust
application
targeting
Python
users,
Python
application
developers,
and
there
were
a
handful
of
people
who
complains
that
I
did
not
provide
a
standalone
executable
for
pi
oxidizer
because
they
and
they
didn't-
want
to
go
through
the
hassle
of
installing
rust
up
and
installing
a
compiler
tool
chain
and
all
that.
B
B
So
essentially,
what
pi
oxidizer
is
is
a
tool
that
it's
written
in
rust
that
enables
you
to
take
a
Python
application
and
compile
it
down
to
a
single
file
as
small
as
a
single
file
executable,
which
then
you
can
give
to
someone
else,
and
they
can
just
installed
on
their
machine
and
run.
It
contrast
that
with
the
the
xkcd
comic,
which
is
you
know,
crazy
right
and
so
from
from
normal
tooling
perspective,
like
pi,
oxidizer
is
just
some
command-line
tool
that
you
use
to
enable
people
to
package
Python
applications.
B
It's
all
the
same
different
manifestations
of
the
same
problem,
and
so
one
of
the
things
that
PI
oxidizer
does
is
we
have
to.
We
have
to
build
a
special
distribution
of
Python
that
is
compiled
with
all
of
its
dependencies
from
source
in
such
a
way
that
the
binary
is
is
portable
to
different
machines.
B
This
problem
is
probably
has
probably
consumed
more
of
my
time
than
writing
PI
oxidizer
itself,
because
build
systems
are
hard
and
I'm
making
build
systems.
Do
things
like
C
pythons
build
system
do
things
that
it
was
not
intended
to
do,
but
at
the
end
of
the
day,
what
happens
is
that
basically,
we
produce
a
set
of
object
files
that
you
would
normally
get
from
your
compiler
put
those
in
a
in
a
tarball
and
then
tell
rust
to
relink
what
pi
oxidizer
does.
Is
it
consumes
those
the
metadata
for
the
Python
distribution
figures
out
like?
B
Oh,
you
want
the
ssl
python
extension
that
requires
all
of
these
libraries.
These
object
files,
all
of
that
packs
that
are
oxidizer,
integrates,
tells
cargo
which
object
files
to
bring
into
the
build
and
then
that
then
cargo
will
link
together
a
rust
application
as
if
it
was
coming
as
if
it
was
a
c
library
or
something
like
that
kind
of
hard
to
explain,
and
I,
if
you
want
to
know
more
details
about
how
that
works,
I
would
you
can
ask
me
after
the
talk,
and
so
are
there
any
questions
so
far?
B
B
Am
using
the
c
python
build
system,
but
there
are
a
number
of
patches.
I've
had
to
apply
at
build
time
to
get
it
to
do
the
things
that
I
once
my
intention
is
to
make
a
lot
of
those
up
streamed
at
some
point:
I'm
not
there.
Yet
I
want
to
kind
of
figure
out
what
all
I
need
to
do.
First
before
I
start
sending
crazy
patches
to
python,
because
I
suspect
the
gonna
be
skeptical.
B
Yeah
so
I
when
I
was
at
Firefox
one
of
my
jaw
or
bananas
at
Mozilla.
One
of
my
Jobs
was
to
be
a
maintainer
of
the
Firefox
build
system,
and
one
of
my
takeaways
from
that
was
that
it
is
often
less
effort
to
just
rewrite
the
build
system
for
a
third-party
project
than
to
coerce
that
build
system
into
doing
what
you
want
and
it
hates
from
I
hate
saying
that.
B
B
B
So
pi
oxidizer
will
it's
basically
a
lot
of
build
system
hackery
around
cargo
and
pythons
build
system
to
produce
a
executable
that
contains
an
embedded
version
of
Python
and
at
runtime?
What
makes
what
makes
PI
oxidizer
different
from
actually
I'll
get
to
that
later,
but
so
applications
built
with
PI
oxidizer
are
just
normal.
They,
like
their
normal
rust
applications,
there's
a
main
function.
It
just
so
happens
that
that
main
function
instantiates
a
rust,
destruct,
defining
how
to
run
a
Python
interpreter,
and
then
it
calls
a
run
function.
B
It's
pretty
simple
and
the
the
code
in
in
rust
at
runtime
is
something
like
it
there's
a
little
bit
of
extra
code
here,
because
there
are
some
runtime
tricks
and
these
are
kind
of
low-level
Python
II
things
I,
don't
know
how
relevant
this
will
be
to
this
audience,
but
it
may
be
relevant
if
others
want
to
explore
how
to
do
this
for
other
languages
like
Ruby.
So
the
one
of
the
nifty
things
that
PI
oxidizer
does,
which
I
believe
is
the
first
project
to
do
this
in
a
cross-platform
way.
B
Is
it
actually
achieve
a
single
file
executable
with
no
external
dependencies
without
any
additional
runtime
tricks?
So
other
tools
in
this
space
will
do
things
like
create
a
task
wash
FS
file
system
or
they'll,
create
a
temp
directory
and
extract
the
Python
standard
library,
that's
embedded
as
a
zip
file
into
some
file
system
and
then
they'll
use
they'll,
tell
Python
hey
the
modules
are
over
here
and
that's
how
things
work
that
can
add
a
substantial
runtime
penalty.
B
Get
into
this
in
the
next
slide,
it's
parsed
into
a
hash
map,
a
rust
hash
map
of
like
here's,
here's
all
the
modules
that
you
have
available
and
then,
when
pythons
import
system
runs,
it
calls
into
a
python
extension,
that's
implemented
in
rust
and
that
extension
does
basically
the
equivalent
of
a
rust
hash
map
hook
up
and
it's
like
do.
I
have
information
on
this
module.
B
If,
if
you
have
like
multiple
directories
on
your
sis,
it
has
to
look
in
all
those
locations
and
there's
all
these
rules,
for
you
know
the
priorities
of
things
I'm
going
to
skip
this
real,
quick
and
go
back
to
it.
But
to
give
you
an
example
of
this,
so
what
PI
oxidiser
does
is
because
it's
loading
all
of
this
from
memory
without
having
to
touch
the
file
system.
The
overhead
of
starting
a
Python
interpreter
is
substantially
mitigated.
B
So
I
also
said
that
I'm
on
the
I'm,
a
core
contributor
to
the
mercurial
version
control
tool
a
few
years
ago,
I
measured
how
long
it
took
like
the
test
harness
to
run,
and
you
run
on
a
laptop.
It
takes
like
20
minutes
to
run
the
full
mercurial
test
harness
and
when
you
start
digging
into
where
that
time
is
spent,
it
turns
out
that
Python
interpreter
startup
overhead
is
actually
a
thing
it
you
run
it
from
your
command-line
tool.
We
use
a
tool
like
hyperfine,
which
is
an
amazing,
rust
benchmarking
tool
for
crude
crude
benchmarking.
B
B
We
ran
into
this
in
the
Firefox
build
system
when
you
invoke
Python
for
thousands
of
times
we're
doing
little
miscellaneous
things
as
part
of
the
build
like
this
translates
to
minutes
or
dozens
of
minutes
of
CPU
time.
It's
kind
of
calm,
Susie
and
so
PI
oxidizer
helps
with
this.
By
substantially
reducing
the
amount
of
system
calls
and
IO
required
at
startup
time
in
the
in
the
worst
case,
it's
it's
point:
1
millisecond,
faster
per
import,
and
that's
in
like
the
worst
case
on
modern
hardware.
B
Another
thing
here
is
that
with
PI
oxidizer
you
have
single
executable
and
the
size
of
that
executable
can
be
quite
small.
So
if
you
have
a
typical
Python
installation,
it's
something
like
3000
files
with
with
pi
oxidizer.
If
you
have
just
a
simple
hello
world
application,
that's
stripped
of
of
everything
you
can
get
down
to
it's
like
three
or
four
megabytes,
it's
extremely
small
and
considering
you're
getting
a
you
know
a
full
interpreter
and
a
few
megabytes
in
2019.
B
B
What
is
I
think
more
important
and
more
brought
lots
more
relevant
to
this
group
is
what
pi
oxidizer
can
do
for
rusts
and
for
python
and
pi
oxidizer.
My
vision
for
it
is
that
it
empowers
both
of
these
languages
to
access
new
domains
and
features
if
you're
coming
from
Python
single
file.
Self-Contained
applications
can
give
you
access
that
you
did
not
have
before
so
take,
for
example,
the
ansible
systems
management
tool.
B
It's
a
it's
a
Python
program,
but
to
run
ansible
on
a
server
you
have
to
have
Python
installed,
which
is
it
creates
this
chicken-and-egg
problem
and
you're
like
python.
Has
this
huge
problem
in
in
reality
where
people
aren't
deploying
like
the
latest
versions
of
Python?
So
if
you're
a
project
like
an
Cibola,
you
have
to
tell
people.
B
Oh,
you
need
to
install
a
Python
on
your
server
before
you
can
use
ansible
or
if
you're,
in
building
docker
images
you
have
to
install
Python
before
you
can
use
anything
in
python
and
then
getting
a
modern,
up-to-date
version
of
Python
installed
can
be
quite
laborious.
So
if
you
have
a
single
file
executable,
you
can
just
SCP
that
executable
somewhere
copy
it
somewhere
and
it
just
works
pretty
empowering
it
enables
application
developers
to
target
the
latest
version,
because
the
Python
there
they're
getting
is
the
newest
version.
B
You
can
imagine
use
cases
in
places
like
AWS
lambda,
any
place
that
allows
you
to
execute
an
elf
executable.
You
can
execute
Python,
you
just
have
a
single
file
binary
from
rusts.
If
you're
a
rust
developer,
PI
oxidizer
allows
you
to
easily
embed
Python
to
your
application,
just
by
embedding
a
crate
in
reality.
B
Is
it's
not
very
well
polished
right
now,
but
I
can't
publish
the
crates
on
Chris
dot
IO
because
of
I
think
restrictions
with
dependency,
modified
dependencies,
I
think,
but
in
theory
you
can
you
can
vendor
the
PI
oxidizer
source
code
or
reference
it
and
you
can
embed
pipe.
You
can
use
pi
oxidizer
use,
build
system
to
embed
Python
in
a
rest
application
in
PI,
oxidizer
abstracts,
all
of
the
ugliness
around
you
know.
How
do
you
build
Python?
How
do
you
integrate
it?
B
B
It
means
that
as
a
Python
developer,
the
world
of
rust
dependencies
and
in
crates
are
available
to
you
and
there's
a
lot
of
fantastic
crates
for
rust.
A
lot
of
low
level
systems
things
that,
quite
frankly,
the
the
Python
community
doesn't
have
is
read
ready
access
to
some
examples
are
up
there.
I,
don't
I'm,
not
I'm,
not
condoning
doing
this,
but
like
if
you
really
wanted
to
like
a
command-line
application,
could
ship
their
own
terminal
emulator
for
years.
The
terminal
emulator
on
Windows
has
been
really
bad.
B
Microsoft's
seems
to
be
doing
a
good
job
of
improving
it,
but
it
I
don't
think
it's
quite
there
yet,
but
if
you
could
ship
your
own
gpu-accelerated
terminal
emulator
with
your
program,
that's
pretty
neat.
This
matters
for
things
like
Python
is
really
big
in
domains
that
aren't
necessarily
program
or
heavy
a
lot
of
data.
Now
people
will
are
using
Python
projects
like
Jupiter
notebooks,
which
are
kind
of
these
visual
buoys
that
allow
you
to
do
really
cool
data
analysis,
it's
Python
under
the
hood
or
a
lot
of
it's
Python
under
the
hood.
B
But
if,
if
you
could
make
something
like
a
jupiter
notebook
a
you
know,
a
self-contained
executable
containing
its
own
browser
rendering
engine-
and
you
didn't
have
to
worry
about
installing
all
of
these
dependencies
and
shipping.
All
these
dll's,
like
I,
think
a
lot
of
that
can
be
very
attractive
to
to
application
developers.
B
Another
example:
shipping
a
robust
HTTP
to
server
or
client
I,
don't
think
Python
has
one
in
the
standard
library
right
now.
I
would
love
my
and
I.
Quite
frankly,
don't
trust,
random
Network
protocol,
implementations,
I
trust
things
implemented
and
rust,
and
so,
if
you
could
say,
oh
well,
I
want
to
use
a
rust
crate
to
provide
my
my
networking
stack
from
your
Python
application.
Pretty
cool
I
think.
B
There's
also
a
lot
of
other
ideas
around
how
I
oxidizer
could
be
used
to
accelerate
the
capabilities
of
Python
interpreters
themselves.
I
find
like
the
the
canonical
Python
interpreter
is
implemented
in
NC
and
it's
kind
of
hard
to
hack
on,
but
if
you
are
embedding
a
Python
interpreter
from
a
rust
application,
it's
a
lot
easier
to
kind
of
hack
around
with
new
features
and
and
new
capabilities
of
the
Python
interpreter.
Couple
ideas
I've
had
here
are
to
integrate
a
profiler,
implemented
and
rust.
It's
easier,
I
think
to
do
that
in
rust
than
NC
debug
servers.
B
There's
a
lot
of
crazy
stuff.
You
can
do
swapping
out
the
implementations
of
like
pythons
core
classes
and
replacing
them,
because
the
way
that
PI
oxidizer
works
is
it
combines
object
files
to
form
a
new
Python
distribution
kind
of
on
the
fly.
So,
if
you
wanted
to,
you
could
say
you
know,
I,
don't
like
pythons,
dict
or
list
implementation.
I
want
to
create.
My
own
mercurial
would
love
to
experiment
with
this,
because
every
few
releases
there
is
inevitably
a
bug
where
we
have
a
list
contains
in
a
loop
somewhere,
and
we
have
an
accent.
B
The
quadratic
situation
on
our
hands,
and
so
we've
hypothesized
a
few
times,
wouldn't
it
be
really
cool
if
we
could
test
for
lists
where
contains
is
called
multiple
times
during
a
test,
because
it's
almost
always
a
bug
to
be
calling
list
contains
from
Mercurio.
We
would
rather
use
tuples
or
sets
if
we're
doing
membership
lookup.
So
there's
tons
of
ideas
of
how
we
could
extend
the
Python
interpreter.
B
B
B
Yeah
so
most
the
question
is:
what
happens
if
you
point
file
to
the
current
executable,
a
lot
of
Python
modules
use
file
as
a
way
of
locating
resources
or
files
relative
to
the
current
file,
so
you'll
say:
oh
I
have
a
JSON
file
next
to
my
PI
file.
They
all
look
at
pi,
stripped
the
file
name
strip,
the
the
base
name
of
the
file
and
then
join
the
directory
name
with
the
JSON
file
name
and
then
attempt
to
open
that
path
directly.
B
There
is
an
API
in
python
for
accessing
resources
like
that,
but
it
hasn't
been
stable
for
long
enough
for
people
to
use
it,
and
so
nobody
uses
it
in
reality,
even
though
they
should
I
have
a
massive
FAQ
on
the
PI
oxidiser
Doc's
about
this,
like
I,
think
every
Python
application
using
file
is
arguably
wrong
because,
but,
like
that's
a
religious
word,
I
know
people
like
Google
attempted
to
fight
like
Google,
has
had
single
file,
Python
X
Opel's
for
ages,
using
different
techniques,
but
they
rant.
My
understanding
is
everyone
who's
done.
C
B
I
would
say
it
comes
down
to
personal
preference
I
in
the
case
of
profiling.
That's
very
low-level
things
mucking
around
with
internal
states
I
get
to
this
afterwards.
I
have
a
few
slides
to
finish
the
talk
about
my
personal
thoughts
on
rust
and
I.
Iii.
Just
think
that
in
in
2019
I
I
don't
want
to
be
writing
anymore
C
code
I've
introduced
too
many
security
bugs
and
crashes.
So.
B
But
where
was
I
yeah
so,
while
party
oxidizer
does
have
the
main
goal
is
to
make
it
easier
to
ship
Python
applications
like
we're
not
quite
there.
Yet
we
can
build
the
single
file
executables
and
people
who
already
have
distribution
systems
set
up
or,
if
you're
in
corporate
environments.
You
probably
have
already
solved
this
problem.
So
it's
it's
good
enough
for
you
to
use
today,
but
I
really
want
to
be
able
to
like
on
windows,
produce
an
MSI
installer
on
Mac
produce
a
dmg
or
a
package
on
Linux.
B
We
can
actually
produce
a
single
file,
statically
linked
executable
that
you
can
just
copy
around
and
it
just
works,
but
I
do
want
to
make
it
possible
to
produce
like
rpms
and
packages,
and
these
are
largely
solved
problems.
The
unsolved
parts
is
helped
to
integrate
them
into
PI
oxidiser
again,
I
want
to
make
it
really
easy
so
that
so
Python
application
developers
can
focus
on
the
building
good
applications,
instead
of
toiling
with
build
systems
and
distributing
their
applications,
because
it's
really
a
a
time
consuming
problem.
B
And
I
thought
I
would
use
some
time
up
here
to
talk
about
my
feedback
about
rust,
coming
from
someone
who's
used,
mostly
Python
in
C
for
the
past
five
or
six.
Well,
basically,
my
whole
career,
which
is
more
than
five
or
six
years,
and
talk
about
my
experience
coming
from
those
backgrounds,
I
think
maybe
the
Python
background
might
be
more
insightful.
I
wanted
to
say
that
learning
the
the
efforts
gone
into
teaching
the
language
improved
substantially
between
2017
and
2018
I
tried
to
learn
rust
over
Thanksgiving
and
Christmas
in
2017
and
didn't
have
much.
B
Success
came
back
a
year
later
and
I
was
able
to
to
build
PI
oxidiser
with
what
I
was
able
to
learn,
so
that
was
that
was
impressive.
I
think
the
the
the
really
biggest
this
is
a
long
list,
I'm
not
going
to
go
through
it,
but
the
thing
that
surprised
me,
the
most
about
rusts
coming
from
Python,
is
how
expressive
rust
can
feel
I
naively
assumed
that
rust
being
a
systems,
language
is
going
to
be
very
low
level.
B
What
I
actually
found
out
was
that
it
feels
like
a
higher
level.
Dynamic
language
like
Python,
sometimes
and
I
was
I,
was
really
shocked
by
that
so
much
so
that
I
don't
know
if
I
put
it
up
here,
but
I
think
that
for
me,
starting
starting
most
projects
now
I
I
would
choose
rest
over
Python
even
and
I'm
surprised
by
that
result.
Actually
I
I
would
say
there
are
some
edge
cases,
and
people
can
ask
me
about
these
afterwards.
B
D
B
E
B
B
So
well
in
in
in
PI
oxidizer
right
now,
it's
somewhat
opinionated
and
it
really
wants
you
to
get
towards
a
single
file
executable.
But
there's
nothing
saying
like
PI
oxidizer
can
produce
a
single
file,
Python
binary
that
functions
just
like
the
Python
that
you
would
normally
compile
yourself.
If
you
want
to
do
that,
you
can
I
it's
just
that.
I
haven't
focused
on
building
those
features
out
as
much
because
the
single
file
executable
is
like
the
holy
grail
of
distribution
and
I
wanted
to
solve
that
technical
problem.
B
First,
to
prove
that
it
was
solvable
before
moving
on
to
the
lower
hanging,
fruit
and
I,
fully
anticipate
running
into
problems
with
like
random
C
extensions.
That
I
will
not
be
able
to
coerce
into
compiling
the
right
way
for
them
to
be
distributed,
and
we
all
have
to
I'll
just
have
to
give
up
and
say:
okay,
those
extensions
you
have
more
than
you
don't
have
a
single
file
executable,
which
fine.
F
Hey
Gregory,
this
project
is
really
super
cool
and
it
makes
me
much
more
interested
about
mixing
Python
with
rust
than
I
was
previously,
though
I
have
done
so
on
previous
projects
from
kind
of
a
selfish
perspective.
I
see,
the
part
of
your
plan
is
to
automatically
create
platform,
specific
installers,
which
is
kind
of
a
Holy
Grail,
which
you
may
even
have
mentioned
that
term
and
I'm
wondering
selfishly.
If
you
solve
this
for
single
executable
Python
binaries,
might
you
just
go
ahead
and
solve
it
for
rust
in
general,.
B
This
thought
has
crossed
my
mind
and
the
answer
is
yes,
because
what
I
am
kind
of
doing
here
is
like
from
the
perspective
of
Frost.
Like
these
applications,
we
produce
our
rust
executables.
There
is
some
other
stuff
that
happens
after
the
fact
like
what
PACs
adviser
is
doing.
Is
it
invokes
its
own
build
system
and
then
invokes
cargo
telling
cargo
where
to
find
its
build
artifacts
and
then,
after
it
invokes
cargo,
it
can
copy
the
files
around
in
things
and
so
I
initially
started.
B
This
like
I,
wanted
cargo
to
be
the
driver,
but
then
I
realized
that
the
users
of
this
application
aren't
necessarily
rust
developers
and
I
didn't
want
to
leak
the
existence
of
cargo
to
them
and
so,
like
we
actually
wrapped
cargo.
But
all
of
this
is
does
I
I'm
very
diligent
about
designing
and
implement
about
implementing
software
as
libraries.
B
One
of
my
programming
mantras
is
everything
as
a
library,
and
I
try
to
make
everything
that
I
build,
as
is
modular,
maybe
not
architect,
astronaut
a
modular,
but
I
try
to
make
everything
a
library
first
and
then
stick
on
the
interfaces
afterwards,
and
so
when
I
build
the
distribution
parts
they
they
should
be
if
I
follow.
My
normal
standards
of
programming
should
be
a
bow,
isolated,
rust,
crates
or
something
that
could
easily
be
extracted
for
packaging
and
other
rust
applications
or
projects
could
come
along
and
use
this
for
their
own
distribution
needs
super.
F
B
F
G
B
So
okay
first
question
is
on
pi
PI,
the
mechanism
by
which
pi
oxidizer
consumes
the
Python
distribution
I,
designed
it
to
be
generic
and
abstracted.
So
the
Python
distribution
that
PI
oxidizer
consumes
is
a
tarball
with
a
cop
and
in
an
install
of
Python
a
whole
bunch
of
object,
files
and
static
library
files
and
then
a
giant
JSON
file
describing
where,
but
all
the
object
files
are,
and
so
in
theory
and
I
haven't
done
this.
But
in
theory
someone
could
come
along
and
produce
a
pi
PI
distribution
that
has
this
that
conforms
to
this
art.
B
It's
so
it's
definitely
doable
and
I
I
really
want
to
experiment
with
that
sometime.
The
second
question
is
about
conditional
modules.
By
default,
PI
oxidizer
does
not
sniff,
which
modules
you
use
or
attempt
to
parse
the
source
code.
A
lot
of
the
Python
distribution
tools
and
existence
will
look
at
your
Python
source
code
and
try
to
extract.
Oh
you
you're,
using
this
module
and
I
need
to
include
it
and
then
they'll
throw
out
all
the
modules
that
are
unused
very
brittle
problem
space.
B
H
B
There
are,
there
are
build
system
overhead
times
that
are
problematic
for
pi
oxidizer,
because
I
mean
I'm,
not
I'm,
not
embedding
the
Python
distribution
in
the
PI
oxidizer
binary.
But
in
that
case,
if
you
were
to
replace
an
object
file,
you
would
have
to
consume
a
new
Python
distribution.
It
decompresses
in
a
second
or
two
I
think
that
the
Python
distribution
does,
and
it
reads
the
metadata.
That's
usually
pretty
quick.
For
me,
the
the
slow
part
is
compiling
and
linking
rust.
I
I
B
So
when
you,
when
you
build,
there's
a
Tamil
file
that
configures
the
built
application
and
you
can
that
tamil
file
defines
the
default
execution
behavior
of
the
Python
interpreter
and
it
can,
it
can
provide
a
ripple,
a
Python
Ruppel.
It
can
execute
a
line
of
Python.
It
can
eval
a
Python
string
as
code.
It
can
execute
a
module
as
the
main
module
there's
different
modes
there.
Those
are
the
pre
can
modes.
If
you
want
to
go
lower
level,
you
can
instantiate
your
own
configuration
from
rust
and
tell
it
explicitly
what
to
do
so.
B
I
I
B
I've
definitely
debug
I've
used
PDP
or
PDB
in
in
parks,
advisor
binaries
and
I.
Think
it
just
works,
I,
don't
I,
guess
I,
don't
really
set
break
points
based
on
files,
I
set
them
based
on
modules
and
that
PDB
is
not
confused
by
that
and
PDB
is
part
of
the
Python
standard
library,
so
unless
you've
stripped
it
out
of
the
application
it's
there
and
it's
available.
J
Though
I
work
at
a
work
at
Twitter
on
pants
think
this
work
is
super
super
cool
and
packs
it.
What
are
the
issues
we
have
open
is
had
a
ship
pants
as
a
setting
executable,
even
just
so,
we
can
avoid
having
to
packaged
pants
for
every
single
Python
distribution,
so
import
time
is
something
that
you
can
literally
even
see
with
pants.
So
it's
really
really
cool
to
me.
Pants
is
also
written
in
Russian
Python
and
that's
very,
very
cool
and
we're
looking
back
says
you're
to
perform
that
hey
we're
looking
at
it.
J
You
know,
I
am
seeing
it
it's
very
cool.
The
question
I
want
to
ask
was,
but
yeah
this
project
was
fantastic.
The
question
I
wanted
to
ask
was:
are
there
other
systems
that
kind
of
do
the
importing
from
memory
a
bit
that
you're
doing
this
packs
advisor
that
you
drew
inspiration
from
because
I
mean
I
can
definitely
see.
J
Obviously,
why
it's
it's
super
effective
and
partially
it's
because
I'm
trying
to
make
Scala
compiler
really
really
fast
right
now
and
part
of
it
is
something
vaguely
related
to
to
having
class
files
memory,
for
example,
so
I
thought
that
was
a
really
really
interesting
talking
I
didn't
know
if
you
have
any
inspiration
for
that.
I.
B
I
think
I'm,
aware
of
the
technical
details
and
I
think
they're
open
source,
but
I
I'm,
not
confident
of
that
so
I'm
not
going
to
elaborate,
but
like
I
I
knew
that
others
had
achieved
the
problem,
just
not
in
the
cross
platform
an
open
source
way,
and
so
that
gave
me
the
confidence
to
try
to
explore
this
area
and
do
something
to
figure
out
like
how
to
do
it.
The
right
way
without
grotesque
acts.
K
A
A
So
much
we'll
have
a
brief
5-minute
bathroom
break.
So
if
you
need
to
use
the
bathroom
go,
do
that
also,
if
you
need
more
hydration,
so
you
can
use
the
bathroom
later.
Please
help
us
with
our
beer
problem.
Thank
you.
I
start
the
next
talk
in
five
minutes.
Thank
you
all
right.
So
this
next
talk
is
by
jeremy
Fitz
Harding,
who
is
one
of
my
co-workers
at
Facebook.
A
Jeremy
is
the
tech
lead
of
the
Mononoke
project,
which
is
a
mercurial
compatible
source
control
server
written
in
rust.
He
also
works
on
Facebook's
rust
foundation
team,
which
supports
rust
throughout
the
entire
company.
Now
the
rust
foundation
team
makes
it
sound
like
rust,
is
an
first
class
language
at
Facebook
and
that's
maybe
gonna
be
true
in
the
future,
but
it
wasn't
always
the
case.
So
Jeremy
will
be
talking
about
the
process
of
bringing
rust
home
to
meet
the
parents.
Take
it
away,
Jeremy
Thanks.
L
Hello,
I'm
Jeremy,
so
we
all
have
rust.
We,
you
know,
have
been
using
it
in
various
capacities
over
the
time,
but
now
it's
it's
sort
of
time
to
bring
it
into
the
rest
of
our
lives
and
set
it
up
for
success.
So
that's
essentially
what
I'm
going
to
talk
about?
How
I
am
trying
to
do
that
here
at
Facebook,
so
about
me,
I've
had
about
thirty
years.
L
So
when
you
introduce
a
new
language
to
an
organization
like
Facebook,
you
have
to
make
a
case
for
it,
and
the
case
has
to
be
not
it's
a
better
language.
It
has
to
be
a
lot
better
at
something,
and
it
has
to
be
at
least
as
good
in
every
other
front,
and
that's
because
introducing
a
new
language
is
not
just
a
technical
issue.
It's
a
as.
L
The
previous
talk
said:
you'd,
like
a
language,
is
an
interface
between
what
you
want
to
do
and
the
means
to
do
it
so,
and
you
like
a
new
programming
language,
is
an
intrinsically
risky
proposal
to
introduce
it
into
your
into
your
work
day,
because
you
end
up
with
a
bunch
of
code
written
in
this
language
and
if
it
doesn't
pan
out,
then
you've
got
a
huge
amount
of
extra
tech.
Debt
and
Facebook
is
full
of
engineers
who
are
very
pragmatic
and
they're,
primarily
interested
in
getting
their
jobs
done.
L
L
L
The
the
the
win
here
is
that
rust
safety
guarantees
detect
large
classes
of
serious
bugs
at
compile
time
and
the
early.
You
can
detect
a
bug
the
much
cheaper
it
is
to
fix
it,
so
fixing
something
in
a
compile
loop
when
you're
sitting
there
in
your
editor
is
many
orders
of
magnitude
less
than
finding
it.
Three
months
later,
when
you're
running
around
because
you're
looking
at
the
headlines
saying
Facebook,
is
down.
L
So
what
are
we
talking
about
here?
What's
the
environment,
we're
introducing
rust
into
I'm
talking
primarily
about
back-end
services?
We
have
lots
of
different
kinds
of
code
within
Facebook,
but
I'm,
mostly
sort
of
in
the
back-end
space,
and
so
I'll
talk
about
that.
We
have
like
three
dominant
languages
that
are
most
of
the
lines
of
code
and
probably
most
people's
programming
time,
C++,
Java
and
Python
that
C++
and
the
Java
tend
to
be
services
and
Python
tends
to
be
glue,
holding
everything
else
together.
But
our
code
base
is
extremely
polyglot.
L
L
So
the
reason
for
that
is
that
teams
have
a
lot
of
freedom
about
choosing
what
technologies,
what
languages
and
so
on
that
they
get
to
use,
but
that
doesn't
mean
that
they
can
just
go
off
and
say:
I'm
gonna,
do
this
project
and
brain-fuck,
because
why
the
not
it's
going
to
be?
They
have
to
have
a
good
reason
and
other
people
are
gonna.
Ask
them
like.
Why
did
you
choose
brainfuck?
L
It's
a
really
good
debugging
environment,
and
so
so
it's
not
just
a
matter
saying:
Oh
Russell,
it's
cool.
Let's
try
that
outs
like
how's
that
going
to
fit
in
and
this
code
base
we're
talking
about,
is
huge
and
and
when
I
say
huge.
It's
not
like
each
of
these
individual
languages
have
their
own
sets
of
lines
of
code,
but
they're
all
in
one
great
big
source
repository.
We
have
a
single
like
well
as
a
run
likes
to
say
we
like
bono,
repos,
so
much.
L
We
have
lots
of
them,
but
we
have
three
big
ones
and
all
the
code
I'm
talking
about
here
is
in
one.
So
it's
got
millions
of
files
and
it's
got
hundreds
of
millions
of
lines
of
code
and
there
are
like
many
thousands
of
commits
a
day
and
to
make
that
work
to
make
that
practical,
like.
If
you
imagine
setting
up
a
github
account
and
saying
I'm
going
to
put
five
million
files
under
here
and
blah
blah
blah,
that's
going
to
feel
very
unpleasant.
L
So
to
make
that
work,
we
also
have
to
spend
a
lot
of
effort
on
specialized
tooling.
So
pretty
much.
Every
aspect
of
our
tooling
is
tuned
to
this
environment:
everything
from
source
control
to
build
CAA,
blah
blah
everything,
and
it's
all
with
one
sort
of
overwhelming
goal,
which
is
that
the
amount
of
time
you
spend
waiting
on
tools,
the
amount
of
time
that
that
gets
into
your
inner
loop
should
be
proportional
to
the
size
of
your
project.
L
So,
if
you're
working
on
a
hundred
line
server
that
that
you're
just
editing
and
compiling
it
should
feel
like
you're
working
on
a
hundred
line,
a
hundred
file
repo,
if
you're
changing
one
of
the
core
libraries
header
files
that
affects
every
single
C++
project
in
the
system,
you're
going
to
be
waiting
a
while
for
that.
But
you
know
most
people
aren't
doing
that.
So
what
does
that?
Look
like
from
a
Russ
perspective?
Well,
let's
look
at
the
rest
view
of
the
world,
so
it's
gonna
work,
mm-hmm-hmm.
L
Surprised
all
right
so
I
think
it's
fair
to
say
that
rust
values
of
the
safety
aspects
of
the
language
very
highly.
It's
sort
of
the
underpinning
of
everything
else
that
if
you
didn't,
if
Russ
didn't,
have
the
safety
aspect,
it
would
be
a
cute,
interesting
language,
but
the
wouldn't
necessarily
be
a
lot
of
reason
to
pay
attention
to
it.
L
But
that
said,
it's
a
new
language,
so
there's
a
lot
of
scope
for
experimentation,
there's
no
baggage,
there's
no
prior
art.
We
can
like
choose
to
do
things.
The
way
that
we
want
to,
and
so,
despite
that
one
of
the
core
values
of
rust
is
this
idea
of
stability
that
the
language
and
the
standard
library
change
in
a
very
measured
way
and
they
always
have
backwards
compatibility
or
when
they
break
backwards.
Compatibility
it's
done
in
a
deliberate
way
and
to
offset
that
the.
L
There's
a
very
vibrant
third-party
ecosystem
based
around
crates
I/o,
which
allows
for
lots
of
experimentation,
lots
of
dynamic,
trying
out
new
ideas
without
necessarily
committing
anyone
to
any
one
of
those
and
then
to
make
that
work.
There
is
cargo,
this
tool
which
managers
build
in
dependency
and
offers
a
very
low
friction
approach
to
the
language
like
a
lot
of
people's
first
experience
with
rust.
When
you
see
them
sort
of
say:
oh
I,
love,
rust,
I
trade,
it
out
and
what
they're
saying
is
I
tried
out
cargo
and
it
just
worked.
L
It's
so
easy
to
add
dependencies.
I
add
a
thing
you
know,
and
it's
like
a
huge
selling
point
for
the
language.
So,
as
a
result,
in
a
lot
of
ways,
cargo
is
the
center
of
the
rest
universe,
there's
the
compiler,
and
that
has
a
very
important
role
but
sort
of
off
to
one
side
its
cargo.
That's
in
the
middle,
orchestrating
everything
around
it.
L
So,
as
a
result,
cargo
has
this
very
heavy
bias
towards
rust.
It
treats
essentially
the
entire
world
as
rust
or
other
and
other
gets
a
very
short
shrift,
and
so
basically
non
rust
is
an
on
goal.
For
cargo,
so
that
means
that
cargo
alone
is
not
enough
for
us.
We
have
this
very
complicated
environment.
We
have
lots
of
things
going
on,
and
so
how
can
we
bring
rust
into
our
environment
while
retaining
the
essential
benefits
of
rust
and
also
the
essential
benefits
of
our
development
environment?
L
So
why
are
we
even
talking
about
rust
where's
this
a
thing
that
is
a
subject
of
conversation
at
Facebook
when
I
joined
three
years
ago,
I
joined
the
source
control
team
and
there
was
basically
this
project
sitting
on
the
shelf
saying
we
need
a
new
source
control
server.
We
can
see
the
shapes
of
the
lines
on
the
coat
graphs
and
we
know
what
what
materials
upper
limits
are,
and
we
can
see
than
about
two
and
a
half
three
years.
Those
lines
are
gonna
cross
and
we
don't
have
a
good
plan
for
that.
L
So
let's
do
a
new
source
control
server
that
can
deal
with
the
scale
that
we
anticipate
over
the
next
few
years,
and
so
that
was
the
like
immediate
motivation.
We
need
a
new
thing,
but
we
also
know
that
materials
model
is
good
for
what
it's
good
for,
but
it
wasn't
good
for
a
lot
of
things
that
we
wanted
to
do
so
we
wanted
to
have
a
new
server
that
could
enable
a
whole
bunch
of
new
functionality.
It's
not,
and
so
it's
not
a
mercurial
rewrite,
and
it's
not
even
particularly
mercurial
compatible.
L
It
just
has
to
fit
into
the
same
slot
as
material,
but
also
do
a
lot
more
and
being
a
source
control.
Server
correctness
is
essential,
like
randomly
corrupted
source
files
as
a
complete
non-starter
and
if
you
know
even
had
the
hint
of
that
possibly
happening.
It
would
be
extremely
bad
plus,
but
you
had
to
be
in
a
compiled
language
because
we
were
replacing
something
in
Python
or
replacing
something
with
something
else.
In
Python
when
scalability
and
performance
is
a
concern,
doesn't
really
make
a
lot
of
sense.
L
The
source
control
team
has
been
doing
all
of
the
new
client-side
development
and
rust
as
well,
and
so
our
experience
of
bringing
Mononoke
into
production
showed
that
the
claims
checked
out
that
basically
we
spent
no
time
debugging
memory,
corruption,
issues,
race
conditions,
memory,
leaks,
those
sorts
of
things,
it's
so
hooray
and
nevertheless
we
still
see
core
dumps
in
production.
We
see
stack
overflows
because
we
have
some
overly
recursive
code.
L
L
One
of
the
interesting
things
about
this
was:
they
also
chose
to
use
Tokio,
async
and
pretty
much
I
started
the
project
the
day
that
crates
AO
got
its
first
Tokyo
update.
So
in
a
lot
of
ways
that
was
a
big
bet
and
it
turned
out
in
the
end
pretty
well
so.
Overall,
the
experience
was
good
enough.
That
I
could
make
the
case
saying
it's
worth
and
justifying
this,
for
you
know
justifying
further
investment
and,
let's
see
how
far
we
can
take
it.
So
I
talked
about
the
10x
advantage.
What
does
it
really
mean
for
Facebook?
L
What
is
the
cost
of
a
bug?
So,
as
I
said,
when
you
see
a
headline
Facebook
down
into
the
ground
down
something
like
that,
what
that
means
internally
is
a
lot
of
running
around
a
lot
of
shouting
a
lot
of
looking
through
log
files
and
digging
things
up.
But
fundamentally
it
means
that's
a
huge
amount
of
lost
revenue.
L
There
was
a
user
after
free
in
this
service,
and
it
was
like
five
hops
away
from
anything
that
you
would
actually
see
on
the
front
end
of
the
website,
but
that
was
what
the
root
cause
was,
and
so
because
of
that
combination
of
cost
and
FAL
ability
of
the
software
environment,
we
spend
a
lot
of
effort
on
ways
to
try
and
mitigate
that
everything
from
extensive
code
review.
Lots
of
investment
in
static
analysis,
technology,
lots
of
test
infrastructure,
but
the
end
result
is
they're
all
a
bit
too
late.
L
If
you're
sitting
there
working
away
in
your
code,
you're
typing
away
and
you
hit
compile
you're
typing
away
and
hit
compiled
when
the
compiler
stops
complaining
at
you
in
a
sense,
no
matter
how
experienced
you
are
and
how
cynical
you
are
about
correctness,
you
say
well,
job's
done
something
all
sorted
out.
You
ship
it
off,
you
look
you
go
send
it
out!
L
So,
while
you're
sitting
there
in
your
inner
loop,
editing,
compiling
editing,
compiling
you're,
sorting
out
very
fundamental
problems
before
you
even
commit
the
code
and
then
other
languages
have
those
benefits
like
people
say
that
about
Haskell
that
once
it
compiles
it
works,
but
the
nice
thing
about
rust
is
that
it
looks
a
lot
like
C++
operationally
that
the
final
executable
is
a
standalone,
elf
executable.
It's
got
dwarf
debug
information,
it
has
OS
threads,
it
uses
system
malloc,
you
can
use
your
heap
profiler.
You
can
use
your
other
instrumentation,
you
can
use
fleet
profiling.
L
It
just
looks
like
a
C++
binary
as
far
as
everyone
who's
concerned
about
it
as
a
deployable
artefact.
So
it's
very
appealing
in
that
way,
but
the
one
of
the
really
difficult
things
to
work
out
is:
what's
the
cost
of
bugs
that
didn't
happen.
If
your
whole
thesis
is
that
rust,
Souls,
your
bugs
not
having
bugs,
is
a
kind
of
very
negative
signal.
L
So
that's
that's
the
thing
that
we
really
have
to
work
about,
like
we
don't
yet
have
enough
experience
in
putting
rust
into
production,
to
be
able
to
work
out
like
have
direct,
side-by-side
comparisons,
or
anything
like
that.
So
yeah
that
that's
a
thing
we're
working
on,
but
there's
a
whole
bunch
of
secondary
things
like
I
mentioned
code
reviews
before
with
rust,
because
you
can
trust
them
the
compiler
to
give
you
errors
of
a
whole
class
of
relatively
low-level
bugs.
L
It
means
that
the
code
reviews
only
have
to
focus
on
the
high
level
aspects
of
the
diff
like
is
it
you
know,
design
architectural
details.
You
know
the
wires
the
code
this
way,
not
how
does
it
work
in
precise
detail,
and
so
that's
roughly
I,
would
you
know
complete
hand
wave
fifty
percent
of
a
C++
reviews,
reviewers
effort
is
now
eliminated
and
then
there's
also
the
lower
risk
of
code
maintenance.
When
you're
writing
the
code
in
the
first
place,
you
have
a
complete
mental
model
of
exactly
how
it
should
all
fit
together.
You
sit
there.
L
L
Let's
put
a
new
if
statement
here.
Let's
here's
a
case
that
we
need
to
look
at
plunk
it
in
it,
compiles
ship
it
off
and
then
twelve
hours
later,
like
just
as
you're
getting
to
sleep,
then
you
get
woken
up
saying
that
thing
you
landed
to
solve
that
emergency
bug
caused
even
more
problems,
whereas
in
rust,
if
you
can
encode
all
of
the
invariants
of
your
you
know
of
your
code
in
the
type
system
and
in
the
lifetimes,
then
it
means
that
you're
not
going
to
be
able
to
just
plunk
in
something
that's
clearly
broken.
L
L
It
was
just
a
programming
language
that
they
could
get
stuff
done
in
and
as
Greg
talked
about
like
one
of
the
enormous
costs
of
python
is
just
startup
time.
We
have
little
services
on
every
machine
in
the
fleet
that
pop
up
every
minute
read
a
few
steps
out
of
/proc
shove
them
into
a
management,
interface
thing
and
then
die
off,
and
their
job
is
very
short,
laughs
short-lived.
L
But
I
think
it
really
comes
down
to
the
fact
that,
because
the
compiler
does
have
very
good
error
messages
and
they're
very
actionable,
it
means
that
someone
who's
in
that
inner
compile
loop.
Not
really
knowing
the
language,
but
also
not
being
allowed
to
do
things
that
are
horribly
broken.
They
eventually
end
up
with
something
and
what
they
end
up
with
is
something
that
does
what
the
source
code
says.
L
Whereas
if
you're
a
C++
programmer,
you
can
look
at
the
source
code
and
then
you
can
look
at
your
segmentation
fault
and
you
can
look
at
all
the
manuals
and
you
can
not
draw
any
connection
between
those
and
so,
and
so
you
end
up
with
something
that
doesn't
work,
but
it
does
what
the
source
code
says.
So
then
you
fix
the
source
code
and
then
you
end
it
with
something
that
works
and
that's
that's.
A
positive
experience
and
in
particular,
like
the
startup
cost,
is,
is
very
expensive
for
command-line
interfaces.
L
We
have
tons
of
them
and
it's
kind
of
important
for
a
command-line
interface
to
like
come
up
and
do
something
like
show
a
usage
message
in
100
milliseconds,
but
most
of
our
a
lot
of
our
see
lines
are
written
in
either
C++
or
Python,
and
the
Python
ones
suffer.
The
startup
cost
even
more,
like
there's
a
there's,
a
very
widely
used
tool
that
takes
five
seconds
to
show
its
usage
message.
L
It's
infuriating,
and
so
it
turns
out
that
rust
is
a
really
good
at
doing
these
quick
startup
things
like
the
combination
of
clap
and
struct
uped
has
like
sold
many
people
on
rust
and
I.
Don't
know
if
you're
familiar
with
struct
up
tor
clap,
but
clap
is
sort
of
like
a
general
command-line
library
and
struct
up
is
a
wrapper
around
it
which
uses
procedural
macros.
So
you
can
just
define
a
structure
that
declaratively
defines
what
your
your
command
line.
Interface
is,
and
it's
very
expressive,
and
it's
just
it's
really
nice.
L
It
gives
a
very
good
first
impression,
so
we
have
all
of
these
new
restorations.
How
do
we
support
them?
Well,
most
of
the
teams
who've
decided
to
use
rust
have
not
had
any
experience
rust.
Programmers
on
them,
they've,
basically
been
buying
the
legend
buying
the
myth
and,
as
a
result,
like
part
of
that,
is
being
very
careful
to
make
sure
that
expectations
are
managed
and
that
they're
not
going
to
get
magical
fairy
unicorn
things
unless
you
choose
the
right
libraries.
L
So
as
you
as
a
sort
of
universal
concern
of
that
is
how
long
does
it
take
for?
How
long
is
it
going
to
take
for
my
team
to
ramp
up
how
much
time
am
I
going
to
have
to
write
off
from
this
next
quarter?
Saying
that
we're
not
gonna
get
anything
done,
because
we're
all
learning
any
language-
and
the
answer
is
some,
but
not
nearly
as
much
as
people
expect
like.
L
These
are
very
rough
numbers
and
I'm
kind
of
I'm
very
hand
waving
about
these,
but
I
think
it's
reasonable
to
say
that
people
spend
about
two
or
three
weeks,
just
fighting
the
compiler
in
the
language
and
being
too
out
of
that
and
getting
the
basic
principles
out
of
the
way
and
but
then,
within
about
three
to
five
weeks.
People
feel
reasonably
confident
about
being
able
to
get
something
working
like
they
have
an
idea.
L
In
their
head,
and
they
can
kind
of
work
out
how
to
express
it
and
rust,
it's
not
necessarily
elegant
or
pretty
or
anything,
but
it
gets
the
job
done.
But
then,
after
about
eight
weeks,
people
actually
start
getting
genuinely
competent.
They
feel,
like
they're,
beginning
to
use
the
language
idiomatically
and
get
stuff
done.
L
It
does
depend
quite
a
lot
on
what
language
background
that
the
individual
has
come
from.
Functional
people
from
a
functional
background
tend
to
have
the
best
experience
or
like
rust,
is
the
most
liberating
for
them
from
from
a
more
constraining
environment,
C++
programmers
once
they
work
out
how
rusts
conception
of
life
times
clicks
with
the
model
that
they
have
to
have
to
have
had
in
their
head
to
be
a
successful
C++
programmer,
then
that
Aldus
works
for
them.
L
The
people
at
the
worst
time
are
coming
from,
like
NGO
or
Java,
where
a
typical
program
is
an
enormous,
tangled
mess
of
goo
in
a
mutable
heap,
and
it's
pretty
much
essentially
impossible
to
represent
that
kind
of
structure
and
rust,
certainly
not
idiomatically.
The
biggest
danger
period
is
probably
two
or
three
months
after
the
consistently
idiomatic.
When
someone
gets
in
their
head,
I
understand
traits
now
and
then
and
then
you
end
up
with
things
with
15
type
parameters,
and
you
know
billions
of
constraints
and
ask
me
how
I
know
so.
L
One
of
the
interesting
things
is
that
the
existing
learning
materials
are
really
good
in
the
in
the
external
world,
so
we
haven't
actually
had
to
produce
very
much
internal
material,
certainly
not
about
basic
language
stuff.
There's
a
fair
amount
about
specifics
of
getting
Russ
to
talk
to
weird
Facebook
infrastructure
X,
but
in
general
the
learning
materials
are
really
good,
but
part
of
that
is
building
a
community.
L
So
one
of
the
important
criteria
for
having
a
language
within
Facebook
is
that
there
is
an
internal
community
so
that
a
team
is
not
working
in
isolation
that
if
they
have
questions
they're
not
entirely
on
their
own
working
out
how
to
resolve
those
questions.
So
we
need
to
have
and
maintain
an
internal
community.
L
Secondly,
when
you
have
a
new
team
which
has
got
a
whole
bunch
of
people,
who've
never
used
Russ
before
and
they
all
need
to
review
each
other's
code,
but
they
don't
know
rest.
So
how
do
you
bootstrap
a
review
culture
around
a
new
language
for
these
teams
and
one
of
the
the
basic
mechanisms
that
we
have?
L
This
thing
called
Russ
reviewers,
it's
sort
of
like
a
tag
you
can
just
put
on
your
on
your
change
on
your
PR
and
anyone
who's
subscribed
to
that
can
and
drop
in
and
I've
been
encouraging
people
who
know
Russ
to
do
that,
so
that
they
can
help
bootstrap
other
teams,
Russ
reviews,
but
also
encouraging
learners
to
watch
watch.
Other
reviews
going
on
but
I
cuz
I
think
because
I
think,
looking
at
other
reviews
going
past
is
itself
a
very
strong
educational
mechanism.
L
L
So
we
have
this
very
open
code,
culture,
where
there's
no
sort
of
hard,
like
there's
the
original
authors
of
a
piece
of
code
and
there's
the
team-
that's
currently
maintaining
it,
but
there's
not
a
rigid
line
of
like
ownership,
where
no
one
is
allowed
to
look
at
my
code
and
when
people
are
fixing
things
that
are
going
wrong
in
production.
They
need
to
have
wide
leeway
to
be
able
to
look
at
any
code
and
they
need
to
be
able
to
understand
that
code.
L
L
So
we
have
a
whole
bunch
of
really
enthusiastic
early
adopters.
We
don't
really
need
to
sell
rust
on
them,
sell
them
on
rust.
What
we
need
to
do
is
reach
out
to
the
people
who
want
to
get
their
job
done
and
rust
is
one
of
the
tool
among
many
and
it's
an
interesting
tool,
but
by
far
not
obviously
the
best
tool.
Why
should
I
use
rust?
I've
got
all
the
C++
code.
I've
got
all
these
C++
programmers.
We
have
to
fight
bugs
every
now
and
again,
but
we
kind
of
know
how
to
fight
these
bugs.
L
What
what
why-
and
so
this
is
a
very
incomplete
partial
list
of
some
of
the
arguments
that
we
kind
of
like
float
one
from
earlier
undetected
bugs
are
really
expensive
like
when
they
turn
up
and
bite
you
at
the
wrong
time.
That's
really
expensive,
rust
is
intrinsically
secure.
It's
obviously
possible
to
write
insecure
recipe.
You
kind
of
have
to
jump
through
hoops.
You
have
to
make
an
effort
if
you're
writing
some
code,
that's
touching
random,
untrusted
stuff
from
untrusted
sources,
I
think
it's
probably
almost
it's
almost.
L
It's
certainly
a
very
bad
idea
to
do
that
and
see
your
C++
like
I,
think
rust
should
be
the
default
for
those
cases.
Rust
is
cool
right
now,
so
one
of
the
side
effects
of
it
being
like
Facebook's
philosophy
where
teams
can
choose
their
own
technologies
and
so
on.
It's
also
the
engineers
can
choose
what
they
choose
to
work
on.
No
one
can
tell
you
what
to
do
if
you
feel
that
you
have
a
better
use
for
your
time
than
what
your
manager
is
saying
then
go
and
do
that
other
thing.
L
L
It
looks
very
conventional
and
these
general
observations
I'm
not
going
to
be
true
for
ever,
but
right
now,
as
far
as
I
know,
no
one
told
me
otherwise,
everyone
who's
ever
evaluated
rust
in
the
company
that
I've
heard
of
has
ended
up
deciding
to
use
it,
and
none
of
them
have
decided
that
they
didn't
want
to
do
that
again
and
so
for
what
it's
worth.
That
seems
like
a
good
idea
in
there
and
that
kind
of,
for
example,
libro,
went
public
recently
the
Facebook
blockchain
thing.
L
They
went
through
a
whole
great
big
discussion
about
what
language
to
do
that
in
and
they
certainly
had
rust
enthusiasts
on
the
team,
but
they
had
people
who
are
other
language
enthusiasts
on
the
team
and
they
ultimately
decided
on
rust,
because
management
decided
that
it
was
actually
the
best
trade-off
between
all
the
things
that
they
needed
to
trade
off.
So
you
know
as
an
example.
L
So
where
are
we
now?
We
have
a
solid
stat.
We
have
several
projects
that
are
very
high
profile,
very
strategically
important
that
are
implemented
in
rust,
and
for
that
reason
the
lone
rust
is
not
going
to
fade
away
easily.
But
so
that's
a
good
start.
We
have
many
of
the
like
when
I
say,
standard
API
is
I,
mean
Facebook,
specific
internal
things,
but
stuff
that
everyone
expects
to
be
out
of
excess,
like
I
want
to
access
a
database
and
what
are
logs
some
statistics.
L
I
want
to
you
know,
do
a
whole
bunch
of
things
we
have
those
api's
now
set
up
so
that
it's
relatively
easy
to
write,
rusts
code
and
just
call
those
api's
in
general
and
I'm.
Talking
specifically
here
about
back-end
service
development.
The
experience
feels
comfortable
to
Facebook
developers
like
a
sign
from
the
specific
choice
of
language
that
you're
writing
in
your
in
your
build
descriptions
and
so
on
the
build
process.
The
editing
process
basically
feels
very
similar
to
C++
or
other
languages,
and
it
also
feels
quite
comfortable
to
Russ
developers.
L
You
can
put
a
pound
test
in
front
of
a
function
and
that
becomes
unit
test
and
that's
not
using
rusts
unit
test
framework,
or
it
is
a
little
bit,
but
it's
also
plugging
into
Facebook's
unit
test
framework,
which
is
much
more
extensive
and
keeps
track
of
the
state
of
every
test
everywhere
in
the
entire
system
keeps
track
of
the
pass/fail
rates
and
whether
the
tests
are
flaky
and
whether
or
not
you
know
what
tests
are
associated
with
what
build
targets
and
what
needs
to
get
rerun
one.
So
you
get
all
of
that.
L
Forums
within
Facebook
there's
lots
of
people
going
yay.
We
can
use
rust,
don't
do
use
frustum,
but
but
it's
it's
good
that
people
are
enthusiastic,
but
you
know
we're
not
anywhere
super
substantial.
Yet,
like
I
mentioned
dealing
with
untrusted
inputs,
I
think
rust
ought
to
be
the
default
language
for
anything
security
related
anything
dealing
with
untrusted
inputs,
we're
not
quite
there
yet
I
think
we
can
make
that
case,
but
haven't
yet
the
non
enthusiasts.
The
people
who
want
to
get
stuff
done.
The
rust
is
not
the
obvious
best
answer
to
any
of
their
questions.
L
Yet
at
least
the
threshold
are
still
quite
high.
There
would
certainly
be
people
who
decide
that
rust
is
the
right
language
for
whatever
they're
trying
to
do,
but
not
everyone
there's
some
really
big
holes,
like
our
use
of
rust
doc,
is
abysmal,
we're
basically
not
using
rusts
stock
at
all
internally
and
that's
partly
because
the
rest
up
tooling
is
the
hardest
tooling
to
integrate.
L
C
L
I'm
not
pausing,
because
there's
nothing
and
just
like
there's,
there's
a
balance.
This
there's
a
lot
of
teething
issues,
there's
there's
things
that
are
intrinsically
wrong
with
rust.
There's
things
that
about
the
rust
ecosystem.
That
I
would
like
to
change.
There's
specific
details
of
the
rust
integration
with
Facebook
infrastructure
and
then
there's
having
used
rust
in
practice.
What,
where
does
it
fall
down
and
that's
almost
a
whole
other
talk?
However,
I
would
say
that
the
FFI
traction.
L
What
have
you
got
here?
We
go
so
FF.
I
question
is
quite
rough,
like
we
have
a
lot
of
existing
code
and
being
able
to
interface
with
that
efficiently
sets
a
sort
of
barrier
for
entry
that
makes
it
quite
difficult
and
debugging
problems
around.
There
is
quite
tricky.
We
don't
have
tools
like
sanitizers
that
work
across
languages
and
none
of
our
static
analysis
tooling.
Does
that
and
that
would
be
nice
to
do.
Another
problem
is
that
because
the
ecosystem
is
so
cargo
centric,
it's
quite
difficult
to
get
traction
on.
M
L
Really
because
the
previous
project
I'd
worked
on,
which
was
a
big
non
async
c-curve
base
at
a
previous
company
and
by
the
time
we
realized
that
we
needed
to
be
async.
It
was
basically
impossible
to
retrofit
and
so
I
made
the
early
discrete
strategic
decision
that
going
async
earlier
was
better
than
going
async
later
so.
L
N
Sorry
quick
note:
there
is
one
other
10-x
that
you
actually
kind
of
browsed
over
on
some
of
your
slides
yeah.
If
you
need
systems
level
performance,
rust
has
a
10x
over
c
plus
plus,
and
that
is
onboarding
developers
who
have
never
worked
with
either
you
you
mentioned
the
eight
weeks,
that's
pretty
consistent
with
my
experience,
onboarding,
Python
and
and
node,
and
so
forth.
Developers
and
my
experience
to
be
trusted
with
a
secure
and
you
know,
deployed
in
in
high-stress
environment,
C++
code
base
a
developer
needs
approximately
two
years,
so
a
little
over
80
weeks.
That.
L
N
N
I
mean
in
the
sense
of
having
a
component
that
is
a
pretty
much
stable
application,
that
loads
binary,
shared
libraries
written
in
the
same
language
and
expects
them
to
be
able
to
link
against
a
library
with
stubs
in
order
to
know
what
they
can
depend
on
getting
from
the
runtime
and
providing
a
stable,
a
predefined
interface.
To
that
thing.
So.
L
N
L
I
mean
there's
this
sort
of
stable,
ABI
and
ABI
that
changes
every
six
weeks,
but
generally
in
our
infrastructure.
That
kind
of
dynamism
is
very
frowned
upon.
We
deal
a
lot
in
statically
linked
things,
so
that
is,
that
has
not
been
an
issue,
but
I
could
easily
imagine
environments
in
which
that
would
be
painful.
O
K
L
L
O
So
when
I
eat,
when
I
started
with
rust,
I
was
the
only
Rus
programmer
in
the
building.
There's
only
three
of
us
on
the
team
but
eat
I
would
get
a
borrowed.
Checker
error,
compiler
error
and
I
would
stare
at
it
and
have
no
clue
what
it
was
now
being
really
stubborn
and
I
would
finally
fight
my
way
through,
but
I
would
expect
that
people
would
give
up
on
that
and
give
up
on
rust.
L
I
think
that's
that's
the
importance
of
having
a
community
around
you
and
like
having
someone
sitting
right
next
to
you
saying,
like
you,
you
know
the
experience
that
you
can
stare
at
a
burro,
checker
bug
or
any
particular
bug
for
hours
and
not
make
any
headway,
and
then
you
can
show
it
to
the
person
next
to
you
and
they
go.
Oh
wait.
Why
didn't
you
just
clean
it
here
like?
Oh,
okay,.
L
So
we
have
like
four
here:
we
have
a
lot
of
internal
communities
and
so
making
sure
that
rust
existed
as
one
of
those
from
from
an
early
stage,
and
you
know
things
like
code
review
having
people
you
can
call
in
to
help
out
with
code
review
and
that
person
may
be
an
expert
in
rust,
but
not
necessarily
understand
your
problem
domain.
But
that's
enough
to
get
you
going
by.
E
P
Specific
reason
I
mean
we
could
have
used
C++
or
Erlang,
which
was
an
OTP
language.
I
mean
long
back.
A
lot
of
telcos
used
it
in
the
old
days,
because
it's
more
on
the
paym
I
mean
it.
Eventually,
it
will
be
a
payment
that
you
will
be
using
correct.
It
will
be
a
transaction
money
related
stuff
that
you
will
be
doing
so
I
mean
any
specific
reason
that
we
chose
rust.
L
So
I'm,
not
on
that
team
and
I
can't
really
go
into
a
lot
of
the
details
about
what
they
considered.
But
I
know
that
security
like
not
not
merely
security
but
being
able
to
have
strong,
provable
properties
about
the
entire
system,
is
very
important
and
so
by
eliminating
undefined
behavior
or
making
undefined
behavior
have
a
very
constrained
bound.
L
C
L
C
L
L
So
one
one
of
the
as
I
mentioned
before
we
have
a
whole
bunch
of
teams
in
London,
working
on
very
aesthetic
analysis,
stuff
and
one
of
the
things
I've
been
encouraging
them
to
think
about
is
given
that
rust
eliminates
all
of
the
low-level
problems.
I
want
to
unlock
their
brilliance
and
and
be
able
to
apply
static
analysis
at
a
higher
level
to
rust
programs
so
that
you
can
do
things
like
write.
L
C
Really
emphasizes
how
exploding
exponentially
the
state
space
is
for
anything.
That's
come,
that's
not
causally
related.
So
the
question
is:
how
can
you,
how
can
rust,
help
distributed
systems?
Programmers
understand
the
ordering
events
in
a
distributed
system
when
they
try
to
use
just
distributed
time
stamps,
which
are
obviously
not
possible
in
special
relativity.
C
L
Q
L
So
in
a
small
company,
the
cost
of
an
individual
person
is
much
higher,
relatively
speaking
and
so
at
Facebook.
If
someone
spends
six
months
working
on
a
particular
problem-
and
it
takes
some
six
months
to
do
it
and
they
succeed,
then
they
will
get
a
good
performance
rating
and
they
will
have
done
the
thing
and
that's
person
being
out
for
six
months
will
be
a
bit
of
a
cost,
but
it's
bearable.
L
You
know
five
person
startup
having
twenty
percent
of
your
people
out
trying
to
solve
a
problem
for
six
months
is
huge,
like
that
problem
had
better
be
getting
your
next
round
of
funding
or
you
know
breaking
even
or
something
like
that,
and
so
the
previous
company
I
was
at.
We
were
doing
a
distributed
file
system
in
pure
C.
It
was
in
user
mode,
but
it
was
very
low-level
user
mode.
It
was
a
fuse
file
system
and
we
nominally
had
a
quarterly
shipping
cycle.
So
what
would
happen
is
every
three
months
we
go
well
I!
L
L
That's
that's!
That's!
Let's
have
used
rust
three
years
ago
is
one
argument
you
could
make,
but
it's
pretty
hard
to
implement,
but
these
days
you
could
probably
you
know
you
could
probably
make
the
case
in
a
new
style
of
saying.
Let's
just
start
with
rust
like
this.
Is
the
kind
of
problem
domain
that
we're
working
in
whatever
it
is
rust
is
not
obviously
completely
mismatched
with
it,
and
it's
gonna
give
us
some
benefit,
certainly
if
the
alternative
is
C.
G
L
I'd
love
to
have
that,
but
we
don't,
and
we
don't
I
mean
that
the
amount
of
unsafe
code
that
turns
up
is
very
small,
like
it
really
is
just
around
fi
things:
I,
don't
think
we
have
any
very
few,
maybe
one
or
two
places
where
unsafe
is
used
in
a
way.
That's
trying
to
do
something
that
is
not
purely
related
to
talking
to
another
language.
L
I
would
like
to
improve
that
area,
though,
like
I
would
like
our
code
review
tool
to
flag
dips
that
use
the
unsafe
key
word
extra
loudly
and
like
maybe
have
a
policy
of
to
reviewers
or
something
like
that
have
to
sign
off
and
I
would
love
to
get
sanitizers
working
across
languages
between
C++
and
rust,
and
also
I'd,
like
a
static
analysis
tools
to
understand
across
languages,
and
those
are
things
that
are
not
complete
pipe
dreams
but
are
not
making
a
huge
amount
of
progress
on
them.
Yet,
okay,
all.
A
Right,
so
that's
going
to
be
all
the
time
we
have
for
questions
today,
give
another
big
round
of
applause
for
Jeremy,
like
he
said,
he's
gonna
be
giving
this
talk
again,
a
trust
context
week.
So,
if
you're
gonna
be
a
tres
con
fool
see
you
in
Portland,
we
have
this
room
until
9:00,
so
feel
free
to
mingle
for
the
next
few
minutes,
please
take
some
pizza
or
some
beer
for
the
road
we
need
to
get
rid
of
all
of
it.
There
is
way
too
much.
Thank
you
so
much
for
coming.
Everyone.