►
From YouTube: Should you rewrite in Rust?
Description
E. Dunham
http://lca2018.linux.org.au/schedule/presentation/98/
When coders hear about a promising programming language, they often think "I'd like to write something in that!" While rewriting an existing utility or codebase in a new language can sometimes be a good idea, there are many situations in which it's not -- and to make it even more difficult, the benefits and drawbacks of a rewrite vary greatly based on which languages you're using!
Come to this talk to learn about the various techniques you can use to integrate Rust with existing code in other languages, their pros and cons, and who's using them in the industry. Even if you haven't tried Rust yet, you'll get a crash course in its strengths, its weaknesses, and the many ways you can make it do cool stuff.
This talk was given at Linux.conf.au 2018 (LCA2018) which was held on 22-26 January 2018 in Sydney Australia.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/
#linux.conf.au #linux #foss #opensource
A
So
I
hope
that
you
are
here
because
you
would
like
to
know
about
whether
you
should
rewrite
in
rust,
as
my
own
room,
monitor
I'm,
going
to
double
check
with
our
AV
folks.
Am
I
recording,
maybe
I,
see
I
see
a
yes
gesture
hooray,
so
we
are
probably
live
not
only
to
the
people
here
in
the
room
but
to
everyone
on
the
livestream
and
to
posterity
later
on.
A
So
before
we
get
going
I
just
like
to
know
a
bit
more
about
who's
here
in
the
room
who,
here
by
a
show
of
hands,
thinks
that
you
know
the
answer
that
I'm
here
to
tell
you
for
this
question:
should
you
rewrite
and
rest
yeah?
Hardly
anyone
you
don't
make
any
assumptions,
that's
great,
so
who
here
thinks
that
I
will
tell
you?
Yes,
rewrite
your
code
and
rest
by
a
show
of
hands?
Surprisingly
few,
maybe
maybe
a
dozen
and
who
here
thinks
I'll,
tell
you
no!
No!
No!
Don't
rewrite
your
code
about
the
same.
A
At
the
same
time,
I
work
on
a
bit
on
rusts
infrastructure,
quite
a
bit
on
servos
infrastructure
and
now
on
the
virtual
reality
teams
infrastructure,
that's
part
of
research
as
well,
so,
while
I'm
involvement
and
engaged
with
the
rest
community
I'm
a
member
of
the
rest
community
team
I
do
a
bit
of
rest
programming
but
I'm
more
of
a
compiler
groupie
than
a
compiler
hacker.
But
that's
okay,
because
I
know
a
bunch
of
very
smart
people
and
I
have
combined
my
own
experiences
and
asking
them
a
whole
lot
of
hard
questions
about.
A
What
do
you
ask
when
someone
says
they
want
to
rewrite?
How
can
you
tell
when
you
should
rewrite
something
to
come
to
the
conclusions
that
I'm
going
to
share
with
you
in
this
talk,
so
I'm
going
to
talk
about
whether
you
should
rewrite
your
code
at
all,
whether
you
should
rewrite
in
rust
and
how
to
do
that?
If
it
turns
out
to
be
the
right
thing
for
you,
so
should
you
rewrite
should
is
a
value
judgment
and
all
value
judgments
are
based
on
certain
assumptions.
A
The
assumptions
that
I'm
going
to
make
here
for
us
to
even
be
remotely
on
the
same
page
are
that
I'm,
assuming
that
you're
working
on
some
code
I'm
assuming
that
you're
working
with
some
other
people
on
that
project,
probably
some
of
them
help
you
with
the
code.
Some
of
them
help
you
with
non
code
aspects
of
that
project,
but
you're
not
just
going
it
alone,
and
you
probably
have
someone
who
uses
that
code
that
you're
writing
who
isn't
just
yourself.
A
So
the
other
basic
assumption
that
I'm
going
to
have
to
make
in
order
to
call
things
good
or
bad
is
that
people's
time
and
Happiness
are
ultimately
what
you're
optimizing
for
you're
going
to
basically
try
to
do
the
things
that
make
your
code
save
people's
time
and
make
the
people
happy.
So
those
people
is
not
only
yours.
It's
also
the
colleagues
that
you're
working
with
both
technical
and
non-technical
and
the
people
who
use
your
product
so
anytime
we're
going
to
call
something
good
or
bad.
A
A
Just
get
rid
of
it
just
rewrite
the
whole
thing
and
rest
is,
can
be
enormous.
Has
a
much
more
greenfield
start,
a
new
fewer
constraints
implication
to
it,
but
you
also
get
to
reintroduce
every
bug
that
the
old
code
intrinsically
encoded,
a
solution
for
and
the
larger
a
rewrite
is
pretty
obviously
the
more
time
it's
going
to
be.
Take
it's
going
to
be
taking
that
you
could
have
spent
doing
anything
else
on
your
project,
so
you
can
also
categorize
desires
to
rewrite
code
by
what
someone
hopes
to
get
out
of
it.
A
So
the
main
motivations
to
do
to
try
to
start
tackle
a
project
again
tackle
a
problem
again
from
scratch
that
I've
identified
our
first.
You
want
to
learn
the
tool
that
you're
tackling
it
in
you're
like
I,
want
to
learn
this
new
language,
so
I'm
going
to
write
fizzbuzz
in
that
language,
so
I
know
how
it
works.
Then
there's
the
motor
of
understanding
a
task,
there's
Wow
managing
this
memory
is
really
hard.
A
Maybe
I
should
try
writing
a
similar
piece
of
code
in
a
language
that
helps
me
with
memory
to
see
how
it
works
when
it's
working
correctly
and
finally,
the
one
that's
the
only
really
hear
about
in
popular
conversations
about
rewriting
is
rewriting,
because
you
want
to
ship
different
production
code
to
your
users
than
you're
shipping
right
now,
so
a
rewrite
in
order
to
understand
either
the
tool
or
the
task
is
going
to
be
somewhat
costly.
You're
going
to
spend
a
bunch
of
time
researching
how
to
do
it.
A
Writing
that
code
and
debugging
the
code
until
it
works
in
the
way
that
you
expected,
but
rewriting
with
the
motive
of
deploying
that
rewritten
code
is
immensely
more
expensive.
More
people
have
to
do
research,
coding
and
debugging,
and
you
have
the
communication
overhead
of
explaining
it
to
everyone
else
who
interacts
with
that
code.
You
have
an
obligation
of
backwards
compatibility
if
you're
writing
a
thing
that
you
claim
will
fit
in
and
replace
something.
A
That's
kind
of
sort
of
working
already
and
you
have
whatever
tooling
was
previously
deploying
the
code
is
probably
going
to
need
some
minor
or
major
changes
for
the
rewritten
code
to
work
with
it.
Plus
you
get
the
opportunity
to
introduce
a
lot
of
new
bugs
and
you're
going
to
have
to
fix
them
and
again,
everyone
involved,
not
just
you,
but
your
colleagues,
both
technical
and
non-technical
and
the
users
of
the
product
are
going
to
have
to
learn
about
the
new
system.
That's
starting
to
sound
like
we
should
never
rewrite
anything.
So
why
does
anyone?
A
A
So
when
you're
thinking,
oh
yeah,
okay,
it
looks
like
I
might
want
to
rewrite
this
start
by
thinking
about
how
you'll
communicate
about
it.
This
is
true
not
just
of
rewrites,
but
of
any
major
code
change
and
the
first
step
to
communicating
what
the
problem
is
is
figuring
out
what
it
is.
You
have
to
answer,
as
they
probably
taught
you
in
a
software
engineering
101.
If
you
happen
to
find
yourself
in
a
class
like
that
at
some
point,
you
got
to
ask:
what
does
the
code
do?
What
is
the
code
supposed
to
be
doing?
A
What
will
be
the
consequences
if
I
just
leave
it
be
and
if
I'm
going
to
change
it?
How
will
I
know
when
I've
changed
it
enough?
How
will
I
know
when
the
problem
is
solved,
and
so
once
you've
pinned
down
that
difference
between
what
you
think
is
happening
and
what
you
think
should
be
happening?
You
then
need
to
track
down
its
source,
so
sometimes
that
disparity
can
come
from
you
misunderstanding
one
or
the
other.
Maybe
you
misread
a
document,
maybe
you
misunderstood
someone's
explanation
and
you're
defining
it
in
a
way.
A
That
means
there's,
obviously
going
to
be
a
bug
like
you're
asking
it
to
do
something
it
can't,
or
maybe
there
is
a
problem
this
it
transit
to
a
system
not
to
your
assumptions
about
it,
and
it's
just
the
systems,
architecture
or
the
problem
it's
trying
to
solve
is
just
not
the
problem
that
you
have
anymore,
maybe
lower
level.
You've
got
a
tools
problem.
One
of
your
dependencies
is
doing
the
wrong
thing.
You're
gonna
have
to
go
upstream
and
fix
that
in
order
to
bring
what
it
does
into
line
with
what
you
want.
A
Maybe
it's
the
business
logic.
This
is
where
everyone
tends
to
assume
that
a
bug
is
coming
from,
but
there
are
many
other
options,
because
you
can
have
your
logic
right
and
a
tools
problem
and
get
a
bug.
You
can
have
your
logic
right
and
just
have
the
wrong
architecture
and
get
bad
behaviors,
and
you
can
have
your
logic
right
and
you
can
be
getting
an
unintended
side
effect
just
based
on
some
bug
or
flaw
in
your
program
or
the
ecosystem,
and
that
could
be
introducing
an
unexpected
behavior.
A
So
once
you
have
pinned
down
exactly
where
the
problem
is
that
you're
trying
to
solve
and
where
that
problem
is
coming
from
start
thinking
about
who
will
fixing
it
affect
it'll
affect
you,
because
you're
gonna
spend
a
bunch
of
time
on
this.
It'll
affect
the
other
coders,
because
they'll
have
to
learn
what
you
changed.
It'll
affect,
whoever
writes
the
docs,
whoever
advertises
your
product
and
whoever
uses
the
product.
A
So
in
the
theme
of
history,
repeating
it's
super
important
to
talk
about
what
you're
planning
to
do
in
order
that
people
who've
seen
others
attempt
similar
things
and
fail
for
various
reasons
can
volunteer
you
that
information
and
keep
you
from
making
the
same
mistakes,
so
ask
people
about
the
solution
that
you're
trying
to
do
research.
What
others
on
your
particular
project
have
done
and
research
what
others
on
other
projects
have
done
and
how
it's
worked.
A
What's
worked
well,
what's
work
poorly
and
see
whether
you
can
get
buy-in
from
that
project
when
you
say
hey,
I
would
like
to
make
this
major
refactor
I
would
like
to
rewrite
this
section
of
the
code
in
that
language.
If
people
just
reflexively
go,
oh,
no!
No!
Don't
do
that!
Ask
why
or
if
people
go?
A
So
that
can
mean,
if
you're
doing
a
very
big
change
to
break
the
big
change
up
into
small
incremental
measurable
ones,
a
small
change
it
could
define
it
as
the
cheapest
or
quickest
solution
to
get
the
impact
that
you
need.
It's
the
least
effort
that
you
can
put
in
and
still
get
what
you
wanted,
which,
if
what
you
want
is
a
major
speed-up.
A
Let's
say,
then
that
could
be
a
whole
lot
of
effort,
but
still
don't
do
more
than
you
have
to,
and
introducing
extra
complexity,
just
for
the
fun
of
it
or
just
for
the
fun
of
using
some
cool
tool
will
cause
you
a
lot
of
grief
on
down
the
line
as
you
have
to
live
with
that.
So
basically
risks
multiply.
If
you,
it
was
described
as
innovation
tokens
in
the
previous
rewriting
and
Russ
talk
today,
where
you
have
a
certain
amount
of
risk
you
can
take.
A
A
It's
saying,
I
think
all
those
hours
you
put
in
I
think
you
should
just
throw
them
out
there
regard
it's
saying
well,
I
think
that
the
work
that
you've
been
doing
would
be
super
easy
to
replace.
It
can't
be
that
hard
right
it
why?
Why
do
you
even
spend
so
much
time
on
it?
It's
saying
you
don't
understand
the
engineering
decisions
that
you're
making
because
I
know
them
so
much
than
you
and
fundamentally
to
somebody
knowledgeable,
you're,
seeing
something
about
yourself.
A
You're,
saying
I
have
no
idea
what
you're
trying
to
solve
I,
just
I'm
wandering
in
and
saying
this
one
tool
will
fix
everything.
So
please
don't
do
that
rest
kind
of
has
a
problem
with
this
kind
of
people,
I'm,
not
sure
I
hope
none
of
you
are
in
the
none
of
them
are
in
the
room
or
watching.
If
you
have
done
that
in
the
past
and
you're
hearing,
this,
please
think
about
what
it's
saying
both
about
you
and
the
language
and
consider
not
doing
it
in
the
future.
A
Take
it
look
at
things
from
their
perspective,
start
by
figuring
out
where
their
problems
are
and
how
you're
going
to
bring
them
more
good
stuff
than
the
inconvenience
that
you're
you'd
be
introducing
by
suggesting
a
change.
Look
at
where
their
actual
pain
points
are
respect,
the
amount
of
time
that
people
have
put
into
their
project
and
the
amount
of
understanding
the
complicated
problem
that
their
code
is
trying
to
solve.
That
is
encoded
by
every
bug
fix
that
makes
their
code
look
a
bit
messy
and
ask
whether
they
would
be
interested
in
a
solution.
A
So,
let's
talk
in
a
bit
more
detail
about
rewriting
for
the
sake
of
understanding
the
code,
because
I
feel
like
in
my
upbringing.
As
an
engineer,
it
wasn't
explained
to
me
nearly
as
well
as
I
would
have
liked
that
you
don't
always
have
to
push
the
code
you've
rewritten
to
get
benefits
from
having
rewritten
it.
So
a
couple
of
cases
are
the
I'm
going
to
show
you
a
couple
of
case
studies,
but
from
them
I'd
like
you
to
see
what
these
people
are
doing,
right,
they're
picking,
either
a
familiar
task
or
a
familiar
tool.
A
They're
not
introducing
a
bunch
of
new
risks
like
both
an
unfamiliar
task
and
a
nun
from
at
once,
and
it
sets
them
up
for
success
to
change
a
small
thing
at
a
time,
they've
documented
what
they've
learned,
which
is
what
makes
them
so
good
for,
citing
in
a
talk
and
makes
it
easier
for
them
to
look
back
on
their
own
experiences
and
continue
leveraging
the
knowledge
that
they
gained
and
they
really
take
the
lessons
that
they
learned
back
into
their
other
projects.
So
one
instance
of
rewriting
in
order
to
understand
the
codebase
is
Carol.
A
That's
kind
of
slow
I
wonder
if
thrust
could
make
it
faster,
so
she
assessed
it,
took
it
away
on
her
own,
just
wrote
a
rest
implementation
by
studying
the
C
code
and
then
has
offered
that
as
something
that
people
can
choose
to
use
doesn't
try
to
force
anyone
else
to
use
it,
but
basically
picked
the
the
smallest
component,
which
in
her
case,
was
the
the
library
for
compression
and
then
just
rewrote
that
learning
from
the
knowledge
that
was
encoded
in
the
old
version.
Another
instance
of
rewriting
to
understand
code
is
a
project.
A
The
BART
gave
a
talk
about
at
the
Portland
rest
meet
up,
which
was
advent
of
code,
and
he
had
some
familiar
problems,
problems
that
were
algorithmically
pretty
straightforward
to
him,
but
one
did
the
practices
rest,
and
so
he
resolved
the
problems
in
rust
and
published
them.
And
that's
fine
he's
not
going
to
anyone
and
telling
them
hey
you.
Should
you
should
ship
these
rust
solutions,
he's
just
rewriting
to
understand
and
can
take
that
knowledge
about
how
to
handle
memory
and
how
to
handle
safety
that
he
learned
from
rust
back
to
his
other
project.
A
So
with
that,
out
of
the
way,
a
lot
of
the
time
when
you
talk
about
a
rewrite,
you
are
talking
about
the
problem
where
production
code
isn't
where
you
want
it
and
you
need
new
production
code
for
some
reason.
So
the
first
thing
to
ask
is
always:
can
we
solve
the
problem
in
the
current
language,
the
purpose
of
your
current
language?
You
already
know
it.
A
It
pretty
much
encodes
your
project,
knowledge
about
the
problem,
so
the
better
you
can
leverage
that
the
fewer
reintroductions
of
bugs
that
you'll
have.
So
there
are
times
when
you
think
no
we've
just
got
to
toss
it
and
rewrite
it
when
you
could
actually
refactor
it
in
your
current
language
and
be
fine.
Here's
a
few
common
excuses
like
oh
but
it's
slow.
My
language
is
slow
and
I
want
my
code
to
go
fast.
A
Can
you
find
and
refactor
the
hot
code
so
that
it
doesn't
trip
on
those
problematic
edge
cases
of
your
current
language
and
tooling,
and
can
you
find
a
faster
implementation
of
your
current
language
or
your
current
runtime
or
whatever
bit
is
slowing
it
down?
If
your
current
code
is
confusing,
then
writing
the
say.
A
similar
thing
with
similar
processes
in
a
different
language
is
just
going
to
end
up
confusing
again,
unless
you
figure
out
how
it
got
that
way
and
fix
it.
A
So
learning
how
to
document
better
pruning
out
dead
code,
simplifying
and
refactoring
are
essential,
first
steps
when
your
code
is
confusing
and
then,
if
you
think,
you're
going
to
have
to
change
change
languages
eventually,
you
can
start
by
documenting
that
boundary,
where
you're
going
to
interface
with
the
new
language
and
often
by
singling
out
for
the
problem
pieces
of
code
that
you
wish
were
in
a
different
language
and
documenting
extremely
clearly
everything
around
them.
You
can
reduce
a
lot
of
the
ambiguity
that
was
causing
you
problems
to
begin
with
and
another.
A
Unfortunately,
common
reason
that
some
projects
will
consider
just
rewriting
in
some
other
language
is
that
people
are
bored
of
the
existing
one.
If
you
have
a
group
of
people
who
are
going
to
get
bored
with
one
language,
what's
to
say,
they're
not
going
to
get
bored
with
the
next
one,
so
a
rewrite
is
not
going
to
solve
problems
there.
Some
ways
that
can
sometimes
make
people
get
less
bored
or
give
more
recognition
and
kudos
for
the
contributions
that
people
are
making
communicate
better
about
the
costs
of
making
changes.
A
You
don't
need
have
people
speculate
or
research
what
those
costs
would
be
and
potentially
make
it
more
fun
to
fix
the
things
that
you
wish
they'd
be
spending
time
on
instead
through
whatever
means
that
might
take
so
sometimes,
though,
a
refactor
won't
suffice.
Sometimes
you
have
just
hit
the
wall
on
what
your
tooling
can
do,
or
you're
looking
forward
and
you're
seeing
well.
I
can
get
up
to
this
local
maximum,
but
that's
that's
the
best.
A
A
Who
here
has
light
worked
on
rust
code
in
some
capacity
so
about
maybe
10
or
20
people,
so
I
will
go
through
the
what
rust
is
and
when
you'd
want
to
use
it
for
both
the
benefit
of
those
who
haven't
had
the
chance
to
work
with
it
yet,
and
anybody
on
the
stream
and
the
future
recording
who
will
be
a
little
bit
curious?
So
rust
goals
include
memory
safety,
basically
in
any
language
that
lets
you
manage
memory,
there's
a
bunch
of
rules
that
the
program
is
suppose
or
that
you're
supposed
to
follow
as
a
programmer.
A
In
order
to
avoid
making
mistakes
and
with
rest,
you
have
the
option
of
having
the
computer
check
that
you
followed
those
rules
instead
of
just
hoping
you
did
it
right,
rust
shoots
to
be
as
performant
as
C,
and
we
do
this
with.
What's
called
zero
cost
abstraction,
which
means,
basically,
you
can
get
the
same
code
to
run
on
the
machine,
regardless
of
a
few
write
it
in
the
way
that
makes
the
most
sense
to
a
machine
or
in
the
way
that
makes
more
sense
to
a
person.
A
So
the
higher
level
abstractions
won't
slow
your
code
down
and
it
has
a
minimal
runtime.
It
has
no
interpreter
no
virtual.
You
rely
on
no
garbage
collection
or
any
of
that
you
get
similar
guarantees
to
what
you
would
from
garbage
collection
about
memory
use,
but
those
are
calculated
at
compile
time
instead
of
at
run
time.
A
So
when
you
get
started
with
rust,
you'll
hear
things
that
sound
kind
of
contradictory
they'll
be
like
oh
yeah,
you
have
guaranteed
memory
safety,
except
sometimes
you
don't,
and
this
kind
of
thing,
and
that's
because
rest
covers
a
lot
of
space.
By
offering
you
a
lot
of
different
choices,
the
first
choice,
you'll
get
is:
do
you
want
stable,
rest
or
nightly
rest?
The
stable
rest
is
always
backwards
compatible
with
the
other
stable
rests,
and
so
it
moves
more
slowly.
A
It's
not
exactly
a
long-term
support
which,
if
you
need
a
language
that
will
remain
identical
for
five
or
ten
years
at
a
time
for
your
application.
Rest
is
probably
not
going
to
be
the
best
choice
for
you.
Yet,
unless
you
don't
mind
being
on
a
pretty
old,
stable
nightly
rest,
on
the
other
hand,
is
all
of
the
bleeding
edge
features
that
we're
trying
out.
We're
not
sure
if
these
are
going
to
work.
We're
not
sure
if
the
nightly
is
gonna
work
but
Yolo.
A
Let's
go
try
things,
so
all
stable
code
should
run
on
nightly
if
it
doesn't,
if
it's
a
nightly,
but
it's
a
nightly
bug,
but
there's
a
lot
of
features
in
nightly
that
won't
necessarily
run
on
stable,
basically
right
and
stable
rest
for
as
long
as
you
can,
but
you
may
find
a
dependency
that
requires
you
to
use
nightly
and
it's
very
easy
to
use
both
of
them
at
the
same
time,
on
your
computer
with
some
tooling
I'll,
tell
you
about
in
a
minute.
Russ
will
give
the
you
the
option
of
safe
or
unsafe
code.
A
Most
wrest
code
is
safe,
as
in
we
check
all
of
the
memory
usage
to
prove
that
there
is
no
there's,
no
errors
being
made.
That
you're
not
let's
say
letting
to
different
parts
of
the
code.
Read
the
same
memory
when
they
shouldn't
that
kind
of
thing,
whereas
unsafe
says
this
is
a
circumstance
that
we
can't
prove
that
I'll
prove
it
myself
instead.
A
So
if
you
see
Russ
code
with
some
unsafe
blocks,
that
unsafe
is
a
hint
that
you
should
stare
harder
at
that
to
make
sure
it
doesn't
have,
if
not
doing
anything,
you
wouldn't
want
it
to
when
you're
starting
to
make
your
own
crate
when
you're
starting
a
new
project,
you'll
have
the
choice
of
making
a
library
or
a
binary.
If
you're
going
to
be
integrating
your
rest
code
with
some
other
language,
you
probably
want
to
make
a
library
because
it
can
just
be
called
into
through
that
languages
FFI,
which
I'll
talk
about
in
a
minute.
A
So
you
also
have
a
choice
between
dynamic
and
static,
linking
for
the
code
that
you
produce,
which
dynamic
linking
says
so
with
either
your
depending
on
some
libraries
that
other
people
have
written
with
dynamic.
Linking
you
say,
I'll
just
point
at
the
libraries
elsewhere
on
my
system
and
with
static
linking
you
say:
please
bring
in
a
copy
of
the
bits
of
the
library
I
need
to
my
program.
So
dynamic
linking
will
give
you
a
smaller
program.
That's
a
bit
less
portable
across
machines
and
cross
systems
static.
Linking
will
give
you
a
bigger
program.
A
That's
a
lot
more
portable
and
Resta
also
gives
you
the
option
to
cross,
compile
to
quite
a
few
different
target
platforms.
So
if
loops,
we
added
a
new
platform
and
our
current
language
just
can't
target
it.
But
rest
can
is
your
problem
statement.
Then
a
rewrite
and
rest
might
be
a
great
idea,
so
rust
will
also
offer
you
a
really
good,
tooling
ecosystem
or
a
tooling
ecosystem,
whose
quality
really
surprises.
A
People
coming
from
a
systems,
programming
background
and
feels
very
familiar
to
people
coming
from
a
an
application
programming
background
where
the
languages
can
to
have
a
higher
priority
on
user
experience.
So
when
you're
first
getting
rest
currently
you'll
get
rest
through
and
choose
which
version
of
rest
you
want
to
use
at
any
point
in
time
through
a
tool
called
rest
up,
bear
in
mind
if
you're
listening
to
this
later
on
that
rest
up
is
nearer
to
the
end
than
the
beginning
of
its
lifecycle.
A
At
this
point,
so
it's
worth
doing
a
quick
search
to
see
whether
the
features
have
been
integrated
into
cargo,
which
brings
us
to
cargo,
rests
package
manager
and
buy
package
manager.
I
mean
it's.
The
thing
that
builds
your
project
makes
sure
you
have
all
your
dependencies
builds
all
your
dependencies.
If
you
need
it
to
and
will
let
you
publish
your
project
to
a
public
registry
if
you'd
like
to
share
it
with
others,
karu
can
handle
multiple
versions
of
various
dependencies
when
you
want
it
to
as
well
and
then
in
terms
of
actually
writing
your
code.
A
You've
got
rust
format
which
basically
codifies
a
lot
of
recommended
style
guidelines
for
rust
code
and
will
rewrite
your
code
to
conform
to
those
style
guidelines.
If
you
want
it
to,
and
we
have
the
linter
Clippy
who,
just
like
the
Microsoft
paper,
clip,
will
make
all
kinds
of
helpful
suggestions
except
clippies
are
actually
usually
pretty
helpful
to
make
your
rest
look
good.
So
if
you're
writing
some
rest
you're
a
little
bit
worried
about
sharing
it
with
more
expert
people.
A
They
identified
that
problem
based
on
the
risk
that
it
was
posing
them
essentially,
and
they
made
sure
that
at
the
end
of
the
rewrite
they
would
be
exposed
to
less
risk.
First.
The
first
thing
they
did
was
establish
a
workflow
for
having
rest
as
part
of
the
project
for
testing
the
rest
code,
as
well
as
the
other
code
and
for
shipping
that
rest
code.
That
went
with
the
other
code
that
they
were
working
on,
so
that
that
workflow
has
to
come
first,
because
without
it
you
can't
really
iterate
on
rest
code.
A
That
does
complex
things
and
remember.
The
goal
is
to
make
the
small
changes
one
at
a
time
to
get
where
you
want
to
be.
They
had
a
small
expert
team
of
people
doing
the
rest
part
at
first,
because
the
communication
overhead,
when
you're
iterating
and
trying
new
things
and
trying
to
explain.
Well,
we
tried
that
and
it
didn't
quite
work.
So
we
modified
it
to
try
that
to
a
particularly
large
group,
can
really
slow
you
down
and
they
performed
their
rewrites
incremental
e.
A
They
made
the
first
small
changes
to
make
sure
they
could
ship
rest
and
then
a
slightly
larger
change
to
make
sure
that
all
worked
and
see
how
rest
really
performs
in
the
wild
and
then
once
they
have
that
pipeline
for
adding
rest
to
pain
points
in
their
code.
They
can
proceed
to
add
it
wherever
they
think
that
it's
the
right
solution
with
pretty
little
additional
overhead
so
and
they
left
they
do,
educate
the
larger
teams
working
on
the
product
about
the
rest,
work
that
they've
done,
but
they
put
that
off
until
the
rest
is
succeeding.
A
They
don't
try
to
keep
them
up
to
date
or
with
every
little
detail
unless
they
want
to
opt
in
and
watch
because
again
that
communication
overhead
can
be
huge.
So
the
first
case
study
I'd
like
to
look
at,
is
NPM
the
node
package
manager.
So
you
can
see
those
several
talks
that
I'll
link
because
I
we
have
about
45
minutes
here
and
I'd
like
to
give
you
guys
some
time
for
stories.
At
the
end
there
first
rest
service
was
a
load
balancer.
A
A
A
For
that
for
a
while
to
make
sure
it
was
okay
and
then
they
switched
over
to
the
rest,
one
which
really
mirrors
what
Mozilla
did
shipping
rust
in
Firefox
through
project
quantum,
the
several
excellent
blog
posts
about
the
scope,
which
is
a
huge
scope
of
engineering
work
that
went
into
this,
but
I
like
the
summary
that
Lynn
Clark
gave
of
it.
They
were
rebuilding
a
jet
engine
while
the
plane
is
flying
because
the
top
priority
was
don't
break
Firefox,
don't
break
Firefox
for
the
users,
so.
A
There's
that's
the
huge
difference,
I
think
between
rewriting
anything
versus
just
building
something
new,
and
that's
why
a
lot
of
of
the
companies
who
have
adopted
rest
have
chosen
to
start
new
on
something
instead
of
rewriting
something
existing.
You
can
check
out
the
Friends
page
and
if
you
look
at
the
way
that
the
various
companies
use
rust,
relatively
few
of
them,
are
rewriting
existing
code
compared
to
building
the
new
things
as
they
need
them.
A
So
to
talk
a
bit
more
about
about
quantum,
though
they
they
first
had
to
figure
out
how
the
heck
are
we
going
to
ship
any
rest
code
in
the
Firefox
build
process,
and
that
question
was
answered
by
attempting
to
ship
a
tinyurl
parser
in
rust
to
run
alongside
the
C++
one.
Just
behind
a
feature
flag
turned
off
the
users
will
never
see
that
there's
any
rest
code
in
their
browser,
but
we
can
test
our
build
system,
changes
to
make
sure
that
it
will
build,
and
then
once
they've
made
that
tiny.
A
First
change
to
verify
that
they
could
ship
rest.
They
proceeded
to
port
components
of
an
experimental
browser
engine
servo,
that's
written
and
rust
to
they're,
analogous
portions
of
the
gecko
engine
and
basically
wire
it
all
together.
So
they
they
made
small
changes
a
little
at
a
time
and
only
once
they
were
really
succeeding.
Did
they
bring
in
the
rest
of
the
engineering
team
and
say:
okay
now
you
need
to
start
learning
some
rest.
A
So,
what's
the
techniques
for
rewriting
your
rest
code,
basically,
if
you're
rewriting
you're,
not
throwing
the
whole
thing
out
and
starting
over,
which
I
would
sincerely
recommend
not
to
do
in
almost
all
cases,
you're
rewriting
a
function
or
a
micro
service,
you
probably
are
going
to
need
to
use
foreign
function
interface,
which
is
a
tool
that's
been
around
for
just
about
as
long
as
C
has
for
calling
some
language
which
we
call
the
guest.
In
your
case,
that
would
probably
be
rest
from
the
language
we
call
the
host.
A
There's
gonna
be
four
files:
the
kogo
tamil
configures,
how
the
rests
gets
built
and
what
metadata
the
rest
has
main
dot.
Rs
contains
your
rest
code
main
duck.
Pl
contains
your
Perl
code
that
will
call
the
rests
function
and
the
make
file
builds
the
Perl
code
and
runs
runs
cargo
to
compile
the
rest.
So
your
cargo
duck
tamil.
You
say
what
your
package
is
and
you
give
it
a
library
name.
This
is
going
to
be
a
dynamically
linked
library
because
we
don't
really
care
about
portability
across
platforms.
A
For
a
small
example,
you're
gonna
have
a
main
function.
You
need
the
Nome
angle
directive
here,
because
you
need
to
make
sure
your
function
has
the
same
name
as
it
has
here
to
make
sure
that
it
can
be
called
from
your
other
code
and
you're.
Just
gonna
take
an
integer
and
return
twice
that
integer.
So
in
your
Perl
code,
you
will
use
pearls
FFI
mechanism,
which
there
will
be
something
similar
in
pretty
much
any
language
to
bring
in
that
function
and
make
it
available
to
your
code.
A
So
it's
really
not
as
much
boilerplate
as
you
might
be
afraid
of
to
just
call
a
little
bit
of
rest
when
you
want
to
the
make
file,
works
on
Apple
and
Linux,
and
will
just
run
cargo
build
to
create
the
rest
and
then
run
the
curl
when
you
need
to
so
that's
F,
Fi
and
a
tiny
nutshell,
and
the
other
thing
you
might
need.
If
you're
building
portable
code
is
static
linking
and
to
statically
linked
breasts,
you
can
check
the
docs.
A
You
can
make
a
crate
of
the
type
static
Lib
and
you
can
use
the
muscle
library
in
lieu
of
Lib
C,
because
muscle
is
designed
for
for
static
linking
so
it's
easier
for
the
compiler
to
stick
whatever
function.
It
was
you
needed
into
your
into
your
code
that
you're
emitting
and
you
may
need,
if
you
have
a
bunch
of
dependents,
to
also
recompile
them
with
muscle,
because
your
dependencies
will
be
included
when
you
compile
as
well.
A
So
if
you
can
FFI
from
your
host
language
to
your
to
your
target
language,
and
if
you
can
statically
link
that
rust
that
your
FF
Iying
into
so
it
doesn't
drag
any
extra
dependencies
along
you've,
pretty
much
got
it
made
for
basic
rewriting
sections
of
your
code
and
rust.
However,
a
bunch
of
other
people
have
done
partial
rewrites
and
have
produced
tools
that
you
might
find
fun
and
interesting
if
you're,
using
these
languages.
A
A
Nutshell,
if
you
have
questions
about
rewriting
in
rust,
first
about
rewriting
parts
of
your
code,
rewriting
in
rust
check
with
your
project
in
your
mentors
first,
because
it's
often
as
much
a
cultural
decision
as
a
technical
one,
whether
you're
going
to
rewrite
check
in
your
host
languages,
documentation
for
how
you
can
integrate
with
other
languages
and
when
you
get
to
your
rest,
questions
ask
on
IRC
or
ask
on
the
rest
users
forum
or
contact
the
particular
rust
team
that
you
have
a
very
high-level
question
for
directly.
If
you
need
to.
A
If
you'd
like
to
talk
to
me,
if
you'd
like
to
ask
me
questions
personally,
I'd
recommend
LCA
at
Edina
met
and
I
would
like
to
take
the
last
five
minutes
to
be
a
little
unusual
for
this
conference.
I'm
not
going
to
encourage
questions,
though,
if
you
have
something
you'd
like
for
the
recording
you
may
ask,
but
I
would
like
to
hear
your
short
stories
of
rewrites
and
of
rewriting
code
or
the
impact
that
other's
rewrites
have
had
on
you
or
fun
that
you've
had
with
rust
just
as
a
bit
of
a
chance
to
share.
A
C
Didn't
rewrite
it
in
another
language
but
I.
Just
there
was
some
code
for
implementing
sort
of
LDAP
authentication
for
for
people,
and
but
it
used
non-standard
schemas
and
non-standard
lots
of
things
and
a
very
old
version
of
LDAP,
so
it
I
rewrote
it
as
middleware
and
using
standard
open,
LDAP,
well
standard
schemas,
like
group
names
instead
of
some
made-up
attribute,
so
that
could
work
to
support
other.
C
A
A
D
Sorry
so
I'm
rewriting
an
embroidery
library
in
rust
and
there
are
a
couple
of
projects
that
you
didn't.
Don't
work
that
poorly
in
slipped
under
the
radar.
One
of
them
is
corrode,
which
basically
looks
at
the
C
syntax
tree
and
converts
it
into
rust
and
the
other
one
whose
names
escape
me,
but
basically
is
able
to
generate
C
headers
for
rust
code
and
I
found
that
really
useful.
When
trying
to
use
some
rust
code
and
some
C
codes
together.
Absolutely.
E
A
Is
a
fantastic
question:
there
are
a
few
things
you
could
do
if
the
code
is
public,
I
would
recommend
searching
for
people
who
are
being
sort
of
rewrite
trolls
on
github
who
say
you
should
go
rewrite
that
thing
and
then
hop
into
their
issues
and
say
if
this
project
doesn't
want
you
to
rewrite
it.
I
would
love
to
have
your
help.
If
you
want
to
troll
the
trolls
back
in
in
a
list
in
a
less
snarky
answer,
I
would
say,
find
your
local
rest
meetup
post
on
the
rest
users
forum
frankly
attempt
to
do
it.
A
Do
it,
however,
poorly
and
show
your
attempt
at
the
work
far
and
wide,
because
often
a
poorly
done
thing
will
go
to
people
into
offering
fix
ups
in
a
way
that
a
request
for
advice
just
doesn't
so
some
of
my
greatest
success
with
writing
things
in
languages
I'm
not
familiar
with,
has
been
from
writing
at
very
poorly
and
showing
it
to
some
people
who
are
experts
in
the
language
and
saying
I
tried,
pull
requests.
Welcome
and
they'll
go!
Oh
that
hurts
my
eyes
here.