►
Description
E. Dunham
In some ways, a browser engine seems to have little in common with a web
framework. But both are ambitious software projects, approached by large
groups of diverse people trying and sometimes failing to cooperate,
collaborate, and code together. This talk shares firsthand observations,
collected over 3 years of working within the Rust and Servo teams at Mozilla
as well as volunteering on the Rust Community Team, about what all developers
can learn from Rust's approaches to the universal challenges of code and
community.
https://2019.pycon-au.org/talks/rust-s-recipes-for-code-and-community
PyCon AU, the national Python Language conference, is on again this August in Sydney, at the International Convention Centre, Sydney, August 2 - 6 2019.
Video licence: CC BY-NC-SA 4.0 - https://creativecommons.org/licenses/by-nc-sa/4.0/
Python, PyCon, PyConAU
Fri Aug 2 09:15:00 2019 at C3.3
A
And
with
that
we'd
like
to
announce
our
invited
speaker,
Emily
Dunham,
she
said
DevOps
engineer
at
Mozilla
and
has
been
doing.
It
has
been
doing
a
bunch
of
rust
development
over
the
last
couple
of
years,
but
today
she's
going
to
talk
about
the
community
that
are
similar
to
that's
similar
or
possibly
different
in
the
rust
ecosystem.
And
now
you
might
ask
what
the
similarities
there
well
browsers
are
rather
huge
projects
to
build.
So
our
web
frameworks,
as
we
all
know,
from
the
tango
community
and
yeah
I,
think
I.
A
B
So
I've
got
links
to
my
Twitter
and
to
the
slides
here
in
the
slides.
Before
we
begin,
I
also
would
like
to
acknowledge
the
guard
all
of
the
eora
nation,
the
traditional
custodians
of
this
land
and
pay
my
respects
to
the
elders
both
past
and
present.
So
DevOps
sysadmin
call
it
what
you
will
I'm
an
Oregonian
who
writes
Python
to
make
servers
go
so
why
am
I
in
Australia
talking
to
django
people
about
rust,
I
last
touched
Django
about
a
decade
ago.
B
B
The
rest
part
of
my
career
comes
in
when
in
2015
I
left
University
to
take
a
job
as
the
sole
DevOps
engineer
for
Mozilla
research,
I
spent
the
following
three
years,
embedded
within
the
rest
and
servo
teams,
they're
lowering
the
organization's
diplomas
per
capita,
keeping
the
servers
running
picking
up
grad
school
terms
like
ray
Fi
and
elide
from
casual
conversation
and
generally
enjoying
a
backstage
pass
behind
the
scenes
of
these
world-changing
projects.
So
servo
is
an
experimental
browser.
B
Yes,
that
really
is
the
logo
created
to
explore
the
possibilities
that
rust
opens
up
without
the
burden
of
the
total
backwards.
Compatibility
that
Firefox
has
to
carry
and
rust
is
the
language
that
stack
overflows
developer
survey,
rated
third
most
loved
when
it
came
out
in
2015
and
first
most
loved
every
single
year.
Since
then,
last
year,
I
moved
out
of
research
to
pursue
my
career
goals
elsewhere
in
Mozilla,
but
my
time
with
rust
has
permanently
improved
my
vocabulary
of
solutions
to
common
open-source
software
challenges.
B
I'm
here
to
share
some
of
my
observations
about
how
rusts
code
has
shaped
the
community,
how
the
community
has
shaped
the
code
and
the
questions
that
rust
has
answered,
which
you
should
probably
be
asking
too
I
hope
you
can
forgive
me
if
I
also
accidentally
teach
you
a
little
bit
of
useful
rest
along
the
way.
So
rusts
original
author
Graydon
began
work
on
the
languages
foundations
around
2010.
His
motivation
was
the
difficulties
that
he
and
his
colleagues
faced
when
developing
Mozilla's
gecko
browser
engine
in
C++,
countless
feature
additions
and
removals.
B
Later
rust,
1.0
stable
came
out
in
May
of
2015.
We
celebrate
rusts
birthday
on
May
15th,
often
with
cake,
because
we're
a
bunch
of
nerds
project
quantum
one
of
the
more
Herculean
efforts
in
Firefox
is.
History,
was
about
trying
to
improve
gecko
by
porting
rust
code
from
servo,
and
it
worked.
Firefox
has
shipped
with
rust
components
since
2017,
so
if
you're
viewing
your
Django
site
and
Firefox
you're,
probably
running
some
rust
without
even
realizing
it.
If
you
ask
where
rusts
name
came
from
you'll
get
a
different
answer.
B
Every
time
you
ask
someone,
especially
from
the
people
who
could
be
credited
with
originating
it,
but
the
mascot
is
just
Ferris.
A
rust
ation,
just
like
the
language
of
human
users
call
themselves
this
habit
of
punishingly
funny
names
extends
throughout
the
community.
Although
the
cute
mascot
definitely
helps
rusts
technical
appeal,
is
it
simultaneous
emphasis
on
both
performance
and
safety?
Neither
speed
nor
safety
offered
by
a
language
is
novel
on
its
own.
Before
rust,
the
language
is
best
for
writing.
B
Performant
code
would
basically
hand
you
a
cannon
and
let
you
point
it
wherever
you
want
it,
including
your
own
feet.
If
you
read
the
right
books,
you
might
learn
some
rules
for
writing
safe
code,
but
those
rules
usually
started
with
so
remember.
Every
place
in
your
entire
code
base
where
you've
referenced
this
value
and
then
and
the
languages
didn't
care,
whether
on
purpose
or
by
accident.
You
disregarded
those
rules.
B
There
were
also
languages
designed
to
help
users
write,
provably,
safe
and
correct
code,
but
well,
you
know
how
the
most
secure
server
is,
the
one
that
you
power
off
and
lock
in
a
bank
vault
the
languages
that
prioritize
safety
above
everything
else
were
historically
too
slow
for
production
use,
and
sometimes
they
refuse
to
deal
with
real-world
challenges
like
networking
and
file
I/o
at
all.
Rust
gets
around
this
contradiction.
By
doing
it's
a
verification
at
compile
time
so
once
you're
safe
rest
code
is
able
to
compile
it's
guaranteed
to
be
free
from
undefined
behavior.
B
Instead
of
asking
people
to
remember
all
these
rules
for
writing
safe
code,
the
computer
enforces
them
for
you.
Computers
are
way
better
at
cute
than
humans
at
keeping
track
of
hundreds
of
things
at
once.
So
the
lesson
that
I've
taken
away
from
rusts
in
each
in
the
ecosystem
that
I
try
to
apply
to
other
projects
is
how
useful
it
can
be
to
find
intersections
between
problems
or
projects
that
haven't
been
fully
explored.
B
When
people
who
focused
on
safe
languages
and
people
who
focused
on
fast
languages
teamed
up,
they
managed
to
create
something
that
was
better
than
either
of
those
alone
and
rusts
founders.
Weren't
content
to
just
address
the
apparent
dichotomy
between
code
safety
and
performance.
They
also
set
up
their
community
in
a
way
that
addresses
incompatibilities
between
humans,
I'm
sure,
you've
noticed
in
your
own
communities.
There
are
some
individuals
who
just
won't
be
content
unless
they
can
communicate
a
certain
way
and
there
are
others
who
won't
be
content
unless
they
can
avoid
that
kind
of
communication.
B
Our
solution
to
that
problem
is
rusts
code
of
conduct,
defining
what
behaviors
are
desirable
when
working
with
and
when
working
on
the
language
and
what
behaviors
result
in
warnings
and
then
removal.
This
was
originally
a
controversial
decision.
People
were
accustomed
to
communities
where
whoever
got
there
first
forgot
to
set
the
culture
and
scare
off
anyone
who
disagreed
with
them,
whereas
in
rust
the
leaders
were
explicitly
choosing
the
values
that
they
wanted,
rather
than
just
letting
it
happen.
B
People
who
disapproved
of
the
ko
of
conduct
were
certain
that
refusing
to
accept
contributions
from
those
who
violated
the
rules
would
hurt
the
project.
I
can't
necessarily
blame
them
for
thinking
that
it's
easy
to
assume
that
the
amount
of
contribution
that
each
individual
can
bring
to
a
project
is
somehow
fixed.
So
taking
one
contributor
away
might
reduce
the
total
amount
of
work
that
gets
done
if
all
of
the
people
who
wanted
to
violate
the
Community
Guidelines
just
packed
up
their
keyboards
and
went
home.
B
What
would
we
be
left
with
rusts
big
experiment
with
a
code
of
conduct
has
shown
me
that
excluding
the
people
who
make
a
community
hostile
doesn't
earth
it
and
might
actually
help
the
quality
of
the
codebase.
The
contributors
who
remain
are
able
to
collaborate
better
and
get
more
done
in
a
way
that
more
than
makes
up
for
their
slightly
smaller
numbers.
The
guidelines
aren't
hurting
the
codebase,
but
instead
they're
protecting
our
ability
to
build
and
pass
on
our
understanding
of
it.
I've
watched
the
code
of
conduct
succeed,
but
I
very
personally.
B
Don't
think
that
this
means
everyone
else
has
to
go
apply
exactly
the
same
rules
to
their
project.
I
think
the
code
of
conduct
is
just
one
of
many
potential
ways
to
handle
incompatibilities
between
humans.
It
is
one
of
the
most
successful
techniques
for
keeping
an
open-source
community
healthy
that
I've
personally
seen,
but
that
doesn't
guarantee
that
there
couldn't
be
something
better
down
the
road
so
watching.
Those
first
three
years
of
stable,
rust
play
out
from
my
immersion
in
both
the
compiler
team
and
the
servo
browser
engine.
B
Give
me
a
new
appreciation
of
how
the
habits
of
a
project's
first
developers
shaped
the
whole
future
of
that
project
and
of
every
project
downstream
from
it.
The
first
tutorials
and
example,
programs
in
the
language
are
written
by
the
author,
the
first
users,
ideas
of
the
language
are
shaped
by
the
idioms
and
preferences
expressed
in
that
early
code.
B
I
watched
how
it
was
the
people
who
were
really
passionate
about
the
languages,
promise
and
ideals
who
built
the
libraries
and
then
people
who
agreed
with
the
way
that
those
libraries
were
doing
things
who
used
them
as
dependencies
users
who
found
the
idioms
intolerable.
Didn't
stick
around
to
become
experts,
fortunately,
for
us,
the
first
developers
thought
quite
carefully
about
their
values
and
intentionally
selected
processes
that
furthered
both
their
technical
and
cultural
goals.
They
also
tried
to
avoid
placing
filters
that
they
didn't
need.
B
Hostile
community
or
mandatory
in-person
meetings
can
needlessly
filter
out
contributors
who
could
have
made
a
huge
impact
if
you'd
been
accessible
to
them.
So
since
so
many
tech
habits
seem
to
be
inherited
from
upstream
tools,
let's
take
a
quick
tour
of
how
the
compiler
gets
built.
So
you
can
learn
some
things
about
rest
land
as
a
whole.
How
do
they
add
a
new
feature
to
the
compiler?
Well,
first,
they
talk
about
it
for
the
kind
of
long-form
asynchronous
conversation
that
most
projects
will
use.
Email
lists
for
rust
has
chosen
discourse,
forums
and
github
issues.
B
Moderators
with
the
power
to
alter
history
in
this
way
have
earned
the
users
trust
that
they
won't
abuse
the
power
and
those
few
users
who
truly
can't
stand
the
idea
of
anyone
having
those
permissions
haven't
stuck
around.
So
this
is
a
way
that
a
careful
choice
of
technology,
choosing
forums
that
can
be
moderated
in
a
way
that
supports
our
Community
Guidelines,
has
strengthened
the
project.
It's
now
simple.
B
Changes
to
the
compiler
are
made
directly
by
pull
requests
to
the
rest
repos,
but
more
substantial
changes
need
consensus
from
the
rest
teams
and
also
input
from
the
users.
Substantial
changes
go
through
the
RFC
or
request
for
comment
process.
You
fork
the
RFC's
repo,
you
copy,
the
template,
you
fill
it
out
and
then
you
make
a
pull
request
with
your
language
change
idea.
B
Then
the
appropriate
rest
sub
team
is
assigned
to
triage
it
and
everyone
in
the
whole
community
and
really
on
the
whole
internet,
can
come
to
your
PR
and
discuss
and
debate
the
pros
and
cons
of
it.
When
the
assigned
sub
team
thinks
the
discussion
is
wrapping
up,
they
decide
on
a
disposition.
Will
we
merge
it?
B
Will
we
close
it
or
will
we
postpone
it
for
later,
and
then
they
place
the
RFC
into
a
10-day
final
comment
period
when
anyone
who
thinks
that
their
use
case
really
wasn't
considered
by
the
disposition
can
and
what
they
think
the
team
needs
to
know.
So
this
combination
of
public
discussion
plus
expert
teams,
ultimately
condensing
the
discussion
into
their
idea
of
what's
best
for
the
language
balances
our
need
for
openness
and
inclusion,
on
the
one
hand,
with
the
need
to
arrive
at
decisions
instead
of
just
arguing
forever
on
the
other
watching
rust-red.
B
This
line
between
getting
voices
heard
and
also
getting
decisions
made,
has
informed
the
way
I
look
at
other
open-source
communities.
If
you
discuss
too
much,
you
can
look
for
ways
to
wrap
up
conversations,
even
when
there's
not
a
hundred
percent
agreement.
But
what
happens
when
a
community
swings
too
far
toward
the
decisiveness
end?
What
if
it
feels
like
decisions
are
just
getting
handed
down
from
above,
and
the
contributors
are
feeling
ignored
well,
to
take
a
step
back
and
explain
some
context
for
the
way
that
rust
faced
this
challenge
in
rust.
B
B
However,
the
flipside
is
that
teams
can
look
like
these
scary
or
biased.
Little
cabal's
from
the
outside.
They
meet
something
mysterious
happens.
A
decision
pops
out,
barring
no
resemblance
to
the
preceding
debate
rust
used
to
have
that
problem,
but
we
addressed
it
with
what
we
called
a
no
new
rationale.
Rule.
It
basically
says
that
whether
the
team
decides
to
merge
close
or
postpone
the
RFC.
The
reason
for
the
team's
decision
has
to
have
been
something
that
was
already
publicly
discussed.
B
So
you've
landed
your
RFC
and
now
the
code
implementing
its
suggestions
is
allowed
to
be
merged
into
rust.
All
of
the
code
that
comes
into
the
compiler
does,
through
those
so
through
pull
requests
on
github.
Once
someone
gives
an
approving
review
on
a
pull
request,
saying
yeah
this
implements
the
thing
that
the
RFC
said
it
would.
A
bot
called
Bors
will
run
the
repos
tests
against
the
state
of
the
tree
with
the
patch
applied.
It
then
automatically
lands
the
PR.
B
So
when
a
computer
would
be
better
at
doing
part
of
a
task
than
a
human,
whether
that
task
is
checking
for
use
after
free
in
the
compiler
or
running
a
test
like
Boris
does
risk
makes
the
computer
and
not
the
human,
do
the
work
every
six
weeks,
new,
beta
and
stable
rest
versions
ship,
although
the
features
in
them
have
been
individually
tested
by
Bors,
we're
still
not
totally
certain.
What
that
combination
of
features
is
actually
gonna
do
what,
if
some
difference
in
the
behavior
wasn't
included
in
the
test
suite.
B
B
It
compiles
that
crate
with
the
old
compiler
and
it
records
the
output
that
the
old
tool
chain
gives
when
it
compiles
that
crate,
then
it
takes
the
same
crate
again,
compiles
that
same
crate
with
the
new
compiler
and
notes
what
output
the
new
compiler
yielded,
then
you
can
diff
those
two
outputs
and
any
difference
at
all
means
that
some
feature
that
people
are
using
got
changed.
Sometimes
the
changes
were
intentional,
but
other
times
they
were
an
accidental
side-effect
of
some
nation
of
factors
that
we
didn't
have
tests
for.
B
B
So
the
final
piece
of
culture
from
the
rest,
compilers
development,
that
I've
seen
propagated
through
its
projects,
is
a
certain
delight
in
documentation.
The
quality
of
rusts
books
is
a
point
of
pride
for
those
who
work
on
the
language
and
a
new
feature
often
isn't
well
regarded
as
truly
finished
until
it's
documented
enough
for
users
to
start
incorporating
it
in
their
own
code.
The
cultural
value
of
clear
documentation
shows
up
in
the
code
too.
B
There
are
times
when
the
compiler
forces
you
to
spell
out
exactly
what
you
meant,
not
because
it
needs
you
to
tell
it,
but
so
that
you
can
see
that
later.
So,
that's
a
handful
of
things
to
expect
from
project
cultures
descended
from
the
rest,
compiler
look
for
familiarity
with
working
in
small
teams
or
committees,
a
balance
between
public
debate
and
definitive
decision-making,
willingness
to
invest
in
good
documentation
and
this
enthusiasm
for
transferring
work
from
humans
to
machines
wherever
possible.
B
These
values
can
get
diluted
by
other
constraints
as
they're
passed
along
into
libraries
and
then
into
projects
using
those
libraries
but
they're
always
there.
If
you
look
for
them,
I
think
it's
worth
looking
around
your
own
projects
as
well
to
spot
the
ways
in
which
upstream
developers
influenced
your
culture.
Maybe
it's
in
a
positive
way
by
demonstrating
the
benefits
of
some
technique
that
you
use
extensively,
or
maybe
it's
in
a
negative
way,
because
their
choices
deterred
contributors
who
held
some
conflicting
ideal
to
the
languages.
B
So
we
are
using
this
great
process
to
build
a
language.
But
what
is
the
language
itself?
Good
for
rust
might
be
a
good
choice
for
your
project
if
you
need
a
fast
and
memory
safe
language
and
you're,
using
an
LLVM,
supported
architecture,
rusts
ability
to
compile
efficient
code
is
built
on
the
work
that
the
LLVM
or
low-level
virtual
machine
authors
have
put
in
the
rust.
Compiler
emits
an
intermediate
representation
which
LLVM
transforms
into
an
executable
for
the
target
platform
that
you're
building
your
code
for
by
cooperating,
rather
than
competing
with
the
LLVM
ecosystem.
B
So
if
you
start
looking
for
a
rest
version
to
install
you'll
find
that
you
have
this
smorgasbord
of
choices,
would
you
like
stable,
beta
or
nightly
regular
rest
or
the
2018
edition
flavor
for
a
language
that
tries
to
be
easy
to
use?
Why
are
they
confusing
it
with
all
these
choices
right
from
the
start?
B
Eventually,
if
a
project
or
language
gets
really
big,
it
also
needs
legacy
support
for
decades.
Governments
and
corporations
adopt
the
products
that
users
within
them
selected
and
even
an
annual
release
cycle,
can
be
too
fast
for
them
to
keep
up
with
with
all
of
those
different
sets
of
needs
in
play,
which
group
is
the
one
that
gets
what
they
want.
Well,
as
with
the
speed
and
safety
trade-offs,
rust
answer
to
that
apparent
contradiction
is
how
about
all
of
them.
B
The
stable
channel
of
rest
represents
the
set
of
features
that
the
project
has
committed
to
supporting
long
term.
The
beta
channel
contains
candidates
for
inclusion
into
stable
and
nightly
is
a
bunch
of
experimental
stuff
that
we're
not
even
sure
yet
whether
it's
going
to
be
possible
to
stabilize
eventually,
culturally
restate
ins
are
trained
to
use
stable.
If
you
can-
and
you
only
switch
over
to
beta
or
nightly,
if
you
need
something-
that's
not
available
in
stable,
so
this
structure
of
channel
definitions
helps
streamline
communication
about
features
implicitly
answering
questions
like
will.
B
This
feature
still
be
here
in
the
next
release,
or
should
I
expect
this
to
just
work,
or
might
it
be
a
little
rough
around
the
edges
at
first,
the
plan
for
rust
was
that
every
stable
version
should
be
backwards
compatible
to
every
other,
stable
version
back
to
1.0
forever
and
ever,
but
as
the
language
matured
we
kept
finding
places
where
you
could
get
this
huge
usability
improvement,
if
only
you
could
make
a
little
tweak
to
the
backwards
compatibility.
Just
take
that
one
thing
out
so
crushed.
B
Under
this
pile
of
dependencies,
we
built
an
escape
hatch
that
escaped
from
being
stuck
with
the
usability
drawbacks
of
backwards.
Compatibility
came
in
the
form
of
additions.
Each
new
addition
is
allowed
to
remove
backwards
compatibility
from
the
previous
one
when
the
authors
need
to
do
so
to
improve
other
aspects
of
the
language.
So
like
channels
additions
are
a
social
device
for
communicating
to
users
and
other
developers.
B
What
to
expect
from
a
given
rust
additions
are
a
positive
outcome
from
a
time
when
we
didn't
think
of
everything
at
the
start
of
a
project,
but
we
used
the
established
processes
for
discussing
and
designing
and
implementing
changes
to
the
language
to
retrofit
additions
in
a
backwards
compatible
way
that
met
the
conflicting
needs
of
various
users.
So
this
is
all
sounding
great
right.
B
Let's
jump
on
this
bandwagon
and
rewrite
all
of
our
code
in
rust,
please
don't,
please
don't
form
any
established
projects,
rewriting
it
in
any
language
at
all
would
be
disastrous
for
both
your
reliability
and
your
release.
Schedule
one
of
the
most
valuable
skills
of
rusts
leadership
team
is
the
ability
to
say
no.
No,
our
community
is
not
the
place
you're.
Looking
for,
if
you
want
to
behave
like
this
know,
the
trade-offs
that
would
be
required
to
add
that
feature
are
not
something
that
will
benefit
the
language
at
this
time.
B
B
Don't
immediately
throw
the
whole
thing
out
see
if
you
can
refactor
the
hard
part
into
a
few
separate
functions
with
clear
expectations
about
their
inputs
and
outputs
and
then
try
rewriting
just
those
functions
in
a
language
that
might
be
better
suited
to
their
needs,
yeah
that
language
might
be
rest
and
use
FFI
or
foreign
function
interface
to
embed
the
improved
versions
in
your
original
codebase.
You
might
be
able
to
keep
all
of
the
work
you've
invested
in
the
rest
of
the
project,
while
refactoring
a
former
bottleneck
into
a
language
better
suited
to
handling.
B
So
what
might
using
rust?
Look
like
from
the
perspective
of
someone
who
just
wants
to
fi2
it
and
speed
up
some
hot
code?
Well,
first,
you'll
need
a
rest
compiler.
The
easy
way
to
install
and
run
rusts
locally
is
a
tool
called
rest
up.
You
can
get
it
at
rest
up
RS.
We
like
our
RS
domains.
If
you'd
prefer,
if
you
don't
want
to
curl
it
read
it
execute
it
like
any
other
script
that
you
might
have
written
yourself,
you
can
download
a
release
directly
from
a
standalone
installer
or
you
can
even
compile
it
yourself.
B
B
You
can
check
our
we
IDE
yet
calm
for
the
status
of
rust,
support
in
various
editors,
the
rest
language
server,
the
RLS
that
we
released
in
2017
exposes
an
intermediate
representation
of
rust
code
to
editors
and
gives
a
single
interface
for
the
compiler
team
to
test
and
maintain
for
supporting
all
of
the
different
editors.
So
if
your
editor
isn't
supported,
you
can
add
rest
functionality
for
it
without
creating
extra
work
for
the
rest,
compiler
team
to
have
to
keep
track
of.
So
let's
say
we
found
part
of
a
Python
app.
B
Maybe
it's
part
of
your
Django
site.
That's
just
doing
something
really
slowly,
I've
contrived
an
example.
So
just
pretend
with
me
that
we're
doing
a
site
for
people
who
are
into
numerology
and
we're
gonna
find
their
lucky
digit
by
summing
up
all
of
the
digits
of
all
of
the
integers
up
to
some
big
number
to
get
the
lucky
digit.
For
that
number,
you
can
get
all
of
the
code
I'm
going
to
show
you
a
little
bit
of
code.
It's
not
too
scary.
It's
in
a
big
font
from
github
right
there.
B
If
you'd
rather
read
it
on
your
screen
and
then
on
mine,
so
I
invented
this
problem
because
it
can
force
your
CPU
to
meditate
for
a
rather
long
time
on
rather
large
numbers,
while
also
yielding
an
output
that
we
can
check
for
correctness
by
hand
on
the
small
numbers,
so
I've
written
this
little
numerology
thing
in
Python.
Some
note
pi
has
some
code.
That
does
the
thing
that
our
imaginary
website
would.
How
is
it
going
to
perform
on
large
inputs?
B
I
wrote
a
little
script
gets
timer
dot
pi
in
the
repo
that
compares
the
time
before
and
after
the
code
runs.
Not
super
precise
turns
out,
it
doesn't
need
to
be
here's
a
graph.
That's
going
to
confirm
your
intuition
when
the
inputs
get
big
the
times
get
bad.
The
inputs
get
bigger
the
times,
get
better,
with
no
end
in
sight.
B
If
you're
really
good
at
math,
you
might
be
able
to
change
what
algorithm
you're
using
to
find
a
better
one
instead
of
this
naive
solution,
but
let's
say
that
this
is
a
problem
that
we
can't
just
math
our
way.
Out
of
so,
if
we're
seeing
performance
like
this,
what
can
we
do
about
it?
Well,
we've
already
done
the
first
step,
where
we
factor
out
the
hot
code,
the
difficult
or
the
slow
bits,
the
heavy
lifting
that
the
primary
language
isn't
handling
so
well
into
its
own
couple
of
functions.
Next,
let's
try!
B
Writing
that
exact
same
pair
of
functions
in
rust.
Let's
see
if
the
compiler
optimizations
are
better
at
math
than
I.
Am
they
totally
are
so
here
we
have
our
Python
from
before
on
the
left
and
some
equivalent
rest
code
on
the
right.
They
look
almost
identical.
There
are
a
few
places
where
rust
demands
that
you
state
explicitly
what
you
meant
and
Python
is
happy
to.
Let
you
take
a
guess
and
figures
it'll
be
close
enough,
but
on
the
whole,
it's
a
familiar
structure
with
familiar
control
flow.
I'll
bet.
B
You
can
look
at
this
rest
code
and
tell
me
what
it
does
just
about
as
well
as
you
could
explain
to
me
that
same
Python,
one
of
rusts,
big
differences
from
Python
is
the
white
spaces
only
matter
to
separate
tokens.
Scopes
enclosed
by
curry,
braces
and
semicolons
terminating
expressions
serve
the
purpose
for
which
Python
uses
spaces
or
cabs
and
new
lines.
B
This
irrelevance
of
whitespace
makes
it
possible
to
format
rest
code
in
an
almost
unbounded
number
of
ways,
but
most
of
these
ways
are
almost
impossible
to
read
when
you
want
to
write
idiomatic
rest
use
the
tools
rest
formats
felt
like
that
and
Clippy
rest
format
will
format
your
code
for
you
into
standard,
indentation
and
Clippy
is
actually
helpful.
We're
just
like
that
about
names.
Clippy
will
suggest
other
improvements.
What
else
are
you
going
to
name
a
tool
that
suggests
fixes
for
you
by
using
opinionated
tools
to
standardize
the
spike
Shetty
stuff
like?
B
How
are
we
gonna
format?
Our
code?
We
have
more
human
brain
power
left
over
to
do
the
interesting
parts
like
worrying
about
the
actual
logic.
I
know
that
in
Python,
that
decision
has
been
made
for
you,
but
maybe
you
have
an
analogous
debate
where
you
can
just
pick
a
solution:
that's
tolerable
to
everyone,
automate
that
solution
and
then
move
on
to
whatever
it
was
that
you
were
avoiding
by
arguing
about
those
details
so
to
help
the
compiler
enforce
the
safety
promises
that
it
makes.
Our
rest
functions
have
tight
signatures
at
their
starts.
B
These
say,
for
instance,
I
will
take
an
input
of
the
name,
something
and
the
type
use
64
that
for
an
unsigned
64
bit
in
you
can
look
up
the
types
on
the
repo
and
while
you're
starting
out,
you
can
just
copy
them.
From
example,
code
it'll
probably
be
okay
and
I.
Promise
I'll
give
you
a
back
of
type
of
the
thing
after
the
arrow,
so
another
unsigned
64
bit
end.
B
So,
just
because
it's
possible
to
automate
some
tasks
doesn't
mean
it
would
necessarily
make
life
easier,
forcing
people
to
write
down
what
they
meant,
rather
than
just
guessing
what
they
meant
from
what
they
said
is
one
of
the
best
ways
to
catch
accidental
mismatches
between
what
the
programmer
intended
and
what
they
actually
wrote.
So
rusts
first,
but
first
biggest
difference
from
Python,
of
course,
is
that
rest
code
containing
undefined
behavior
cannot
be
compiled,
no
matter
how
sure
the
author
was
that
their
code
was
right.
B
The
compiler
steadfastly
refuses
to
omit
any
part
of
a
finished
program
until
the
whole
thing
passes.
All
of
its
checks.
I've
personally
noticed
a
level
of
humility
in
expert
rust.
Programmers,
that's
rarely
matched
in
other
language
communities,
I
think,
maybe
being
told
no
by
the
compiler
dozens
or
even
hundreds
of
times
a
day
when
they
were
sure
they
were
right,
changes
a
bit
of
their
certainty
about
their
own
perspectives.
B
So
you'll
see
here
that
I
introduced
a
bug
there.
I
didn't
tell
it
that
I
wanted
that
value
to
be
able
to
be
changed,
and
then
I
tried
to
change
it.
And
it's
like
hey
you,
you
didn't.
You
know
you
might
have
wanted
to
make
that
mutable,
so
don't
be
afraid
of
rust
errors
if
you're
playing
with
it.
We
really
want
them
to
help
you
and
if
you
find
an
error
that
does
mislead
you.
That
is
a
bug.
So
on
the
one
hand,
this
perfectionism
rearranges
the
development
process
from
write.
B
It
then
run
it
to
debug
it
to
more
like
write.
It
then
debug.
It
then
rewrite
it
then
debug.
It
then
research
what's
going
on
and
then
debug
it
and
then
swear
at
it
a
bit
and
then
debug
it
and
then
maybe
cry
and
then
debug
it,
and
then
you
finally
run
it,
but
once
your
code
does
compile,
you
know
that
it's
free
from
undefined
behavior.
You
know
that
if
you
promised
you'd
give
a
certain
type
back
from
a
function,
there
is
no
path
through
that
function.
That
would
yield
any
other
type.
B
So
pretty
cool
we've
got
the
same
code
in
rust
that
we
had
in
Python.
What
comes
next.
Do
we
have
to
rewrite
the
whole
rest
of
the
app
in
rust
to
take
advantage
of
the
speed
ups?
You
know
the
answer
here:
No
most
established
languages,
Python
included,
do
have
foreign
function
interface,
that's
meant
for
calling
C
code
kind
of
like
how
you'd
call
any
other
function,
so
we're
gonna
fib
to
the
interpreter
just
a
little
bit,
but
it's
gonna
be
okay.
B
In
our
Python
code,
we're
gonna,
say:
I
have
the
C
dynamically
linked
library
for
you,
so
we're
gonna,
import,
C,
DLL
from
C
types,
we're
going
to
load
the
library
that
we
wrote
and
then
we're
gonna
call
the
function
from
within
the
library,
so
the
boilerplate
up
at
the
start,
I
inherited
it
from
Alex,
Crichton's,
FFI,
examples,
repo
and
I
think
that
it
probably
makes
the
names
right
so
that
this
works
on
Mac
or
Windows
I.
Don't
personally
run
either
of
those
systems.
So
I've
only
tested
it
on
Linux.
B
B
The
function
needs
to
be
public
and
external
so
that
it's
exposed
in
the
library
after
compilation,
and
we
also
specify
to
a
compiler
that
we're
kind
of
try
and
make
it
look
like
C
once
it's
compiled
and
we
give
the
compiler
the
no
mangle
directive,
which
tells
it
hey,
I'm
gonna,
need
this
function
to
keep
having
the
same
name
in
the
compiled
library.
So
I
know
you
could
optimize
it
so
much.
B
You
call
it
like
three
or
something,
but
please
don't
do
that
this
time
around
now
that
we've
nicely
asked
our
compiler
not
to
mangle
our
function.
We're
also
gonna
edit,
our
cargo
Tamil,
which
is
directives
to
the
build
system
and
package
manager.
That
says
we're
going
to
use
a
20-18
edition
here
and
we're
gonna
be
compiling
a
dynamic
library.
B
So
with
that,
we
can
ask
my
poor
little
laptop
to
contemplate
the
lucky
digits
of
some
bogglingly
large
numbers
and
compare
how
long
the
Python
on
its
own
takes
versus
the
Python.
That's
letting
rest
help
out
for
tiny
little
inputs,
they're
pretty
close
with
the
native
Python,
maybe
even
a
smidgen
faster,
because
it
doesn't
have
the
overhead
of
calling
out
to
some
other
library,
but
when
the
inputs
get
larger.
All
this
timing
is
just
run
on
my
laptop
and
nothing
super
scientific,
but
that's
because
the
differences
on
large
inputs
are
so
big.
B
We
really
don't
need
to
care
if
the
measurements
are
accurate
down
below
might
second
or
even
to
the
nearest
second,
when
we
get
up
there
so
sometimes
speed.
Ups
like
this
are
just
a
testament
to
the
rest,
compiler
or
LLVM
being
better
at
some
clever
math
trick
than
you
are,
but
even
a
clever
math
trick
is
still
a
speed-up.
So
remember
these
are
both
Python
programs
that
I'm
timing.
B
I
was
really
glad
to
be
using
Python
for
everything,
but
the
maths
in
this
FFI
demo
remember
that
familiarity
to
you
is
a
strength
that
a
tool
can
have
if
you
can
personally
build
things
better
and
faster
with
your
favorite
tool
than
with
something
else.
That
tool
is
better
for
you
and
any
language.
Any
tool
is
going
to
sound
great
when
you
focus
on
the
challenges
that
it
solved
well,
rather
than
those
that
are
still
figuring
out.
Rest
included.
B
We've
toured
a
variety
of
rusts
technical
and
social
implementations
that
address
the
interface
between
software
and
humanity.
Today
and
like
rest,
your
language
and
project
cannot
be
everything
for
everyone.
Your
answers
to
these
questions
will
be
different
from
rusts
answers,
but
a
lot
of
the
questions
might
very
well
be
the
same,
so
I
hope
that,
throughout
the
rest
of
this
conference,
we
can
continue
the
conversation
about
how
to
combine
the
strengths
that
different
technologies
have
to
offer.
Thank
you.