►
From YouTube: R-Evolution: A Story of Rust Adoption - Ryan Levick
Description
From the Berlin Rust's October "Rust and Tell" Meetup (https://www.meetup.com/Rust-Berlin/)
"Rust and Tell“ is a monthly event to share ideas, and learn about new things in and about Rust. Meet fellow Rustaceans, share your learnings, get motivated and inspired. We’re open to any and all kinds of talks about any subjects that you think will be interesting to an audience interested in Rust. Whether you're an experienced Rust developer or just getting started, we strongly encourage you to share your learnings.
Ryan Levick: https://twitter.com/ryan_levick
Hosted at Prisma: prisma.io
🎥 Filmed by iStream: http://www.istream.pl/
A
All
right
so
today,
I'm
going
to
be
talking
about
a
revolution
or
an
evolution
at
the
company
that
I
work
for-
and
this
is
a
story
of
adopting
rust
at
that
company,
and
so
you
all
know
me
see
me
before
I'm
Ryan
Levesque.
That's
me
right
there
and
my
co-presenter
is
Sebastian
Fernandes.
He
lives
in
London
or
actually
doesn't
live
in
London.
He
lives
outside
of
London,
and
so
he's
not
here
tonight,
but
he
will
be
in
Barcelona.
So
if
you're
there
say
hello
to
him
and
basically
we.
A
A
Really
what
it
comes
down
to
is
that
there
is
a
a
problem
in
our
industry,
some
might
say
the
billion
dollar
problem,
and
no,
it's
not
no
pointers,
although
that
has
something
to
do
with
it
actually,
and
that
billion
dollar
problem
obviously
affects
Microsoft
is
a
company
quite
largely
because
it's
affecting
everybody
in
the
industry.
You
can
be
sure
that
it's
affecting
one
of
the
biggest
companies
in
that
industry
and
to
be
blunt
about
it,
the
problem
really
is
the
language
C++
and
this
well.
A
Of
course,
that's
going
to
maybe
shock
some
people
in
the
room,
and
we
don't
mean
to
say
that
if
you
use
C++
you're
stupid
because
that's
certainly
not
the
case,
C++
is
an
extremely
powerful
language.
It's
also
an
extremely
important
language
in
the
industry
and
has
got
us
to
the
point
that
we're
in
for
better
or
for
worse
and
of
course,
Microsoft
is
also
has
a
huge
hand
in
C++
we
have
a
compiler
so
for
for
any
troubles
that
C++
has
introduced
to
the
industry.
A
And
that
includes
also
spending
a
lot
money
to
have
people
report
the
bugs
to
them,
instead
of
using
those
bugs
for
nasty
nasty
reasons,
and
this
graph
with
the
show's
over
here
is
basically
memory.
Safety
issues
or
many
memory.
Voter
abilities
security
vulnerabilities
by
year
and
the
good
news
is-
is
that
it's
not
going
up?
The
bad
news
is:
is
that
it's
not
going
down,
so
it's
been
at
70%,
basically
since
2006,
when
this
graph
started
and
probably
long
before
that
as
well,
and
it
has
remained
constant
at
70%.
A
And
so,
of
course
you
know,
Microsoft
is
a
company,
and
so
we
always
ask
ourselves
well,
who
cares?
This
is
actually
costing
us
any
money
or
costing
our
customers
any
money,
and
the
answer
is
absolutely:
it
costs
a
lot
of
money.
In
fact,
here
is
one
figure,
a
hundred
thousand
dollars,
but
wait
this
figures
from
2005
and
at
the
time
where,
when
they
reported
this,
it
was
purposefully
conservative.
A
So
there
are
plenty
of
people
who
believe
that
this
figure
probably
is
now
over
a
million,
and
this
is
per
issue
found,
and
there
are
several
issues
found
per
year.
Certain
issues
can
cost
a
lot
upwards
of
a
billion,
so
we
have
in
2005
when
this
first
report
came
out.
There
was
one
issue
that
came
out
where
the
cost
to
Microsoft
and
to
the
customers,
where
this,
where
this
vulnerability
was
being
exploited,
was
estimated
to
be
over
a
billion
u.s.
dollars,
and
this
is
one
issue.
A
So
if
we
have
let's
say
it's
a
good
year
and
have
two
or
three,
that
is
a
possibility
of
billions
and
billions
of
dollars
being
lost
and,
of
course,
this
doesn't
take
into
account
like
the
pain
and
suffering
that
the
engineers
who
had
to
fix
this
were
or
who
knows.
Maybe
it
was
a
bank
system
or
something
like
that,
and
people
lost
savings
or
something
like
that.
The
these
are
cysts
of
critical
systems
that
people
are
relying
on,
and
sometimes
you
can't
even
estimate
what
the
actual
damage
is
when
they're
exploited.
A
A
A
We
need
better
programmers.
Of
course,
these
dumb
programmers
keep
on
introducing
these
security
vulnerabilities,
and
this
is
what
you
see
on
hacker
news
all
the
time
when,
when
people
talk
about
exploits,
they
say-
oh
I
mean,
of
course,
some
junior
engineer
wrote
this
exploit
if
I
were
working
in
this
company,
this
would
never
happen.
I'm
way
too.
Good
of
an
engineer
to
introduce
these
issues,
and
we
as
as
Microsoft
and
as
the
Microsoft
Security
Response
Center,
are
here
to
say,
is
that
is
not
true.
A
There
is
literally
not
enough
training
that
can
be
done
to
solve
these
issues,
even
if
you
were
able
to
hire
very,
very
skilled
engineers
only
and
give
them
enough
time
to
write
code
as
they
expect
to
write
code.
They
will
still
make
mistakes
now,
let
alone
there's
not
enough
engineers
out
there
that
are
highly
trained
and
C
and
C++,
and
you
have
deadlines
and
things
of
that
nature.
These
mistakes
will
happen
unless
you
make
them
not
possible.
A
Okay,
okay,
that's
fine!
We
can't
have
better
programmers,
but
how
about
another
idea?
We
need
better
static
analysis
tools.
We
need
more
tools
to
say
when
a
programmer,
who's,
writing,
C
or
C++
actually
makes
a
mistake,
and,
unfortunately,
while
this
does
work
to
a
certain
extent
and
has
actually
reduced
the
the
cost
of
a
lot
of
mitigations
that
we've
had
before
it
still
is
not
completely
soundproof
and,
as
we
saw
before,
70
percent
vulnerabilities
year-over-year.
A
This
obviously
does
not
fix
the
core
of
the
problem,
and
so
you
can
throw
a
lot
of
static
analysis
tools
at
C
and
C++.
It
will
find
some
issues,
but
there
are
plenty
of
issues
that
cannot
be
found
because,
basically,
if
you
had
a
static
analysis
tool
good
enough
to
find
all
these
things,
it
would
be
baked
into
the
compiler
in
the
first
place.
So
so
then
we
come
to
our
last
and
the
probably
the
only
good
idea
for
actually
addressing
this,
and
that
is,
we
need
to
make
these
issues
impossible
to
actually
produce.
A
We
need
to
make
it
so
that
they
just
don't
happen
in
the
first
place
at
all
and
there's
one
known
solution
for
this:
that's
been
around
for
a
very
long
time
since
the
1950s
that
addresses
a
large
swath
of
these
problems
and
just
gets
rid
of
them
completely
and
that's
garbage
collection.
So
thank
you
very
much.
That
was
my
talk.
We
should
all
use
garbage.
Okay,
of
course,
not.
Obviously,
we've
still
got
a
few
more
minutes
to
go
so
and
we're
at
a
rust
meetup
here,
so
garbage
collection
has
its
limitations
right.
A
Garbage
collection
is,
is
slow
at
times.
Garbage
collection
is
hard
to
predict
and
if
you're
writing
certain
systems
like
operating
systems,
databases,
browser
engines,
things
like
that.
You
can't
afford
this.
The
the
unknowns
that
come
with
the
garbage
collection.
You
need
a
language
that
is
more
or
less
completely
predictable
ahead
of
time,
and
this
is
why
I,
C
and
C++
continue
to
exist
today.
They
continue
to
exist
because
the
programmer
can
be
more
or
less
sure
of
what's
happening
with
their
program
ahead
of
time.
A
But
of
course
that
comes
with
the
issue
that
we've
already
been
talking
about,
where
you
have
all
these
memory
safety
issues
that
get
get
introduced
because
of
it
and
beyond
this
garbage
collection
doesn't
solve
all
kinds
of
security
issues,
there's
still
other
issues
that
are
possible
even
with
garbage
collection,
namely
around
data
races
and
things
like
that
and
so
Microsoft
as
a
company
long
before
I
joined
and
long
before.
My
colleagues
joined
has
been
sitting
around
and
wondering
what
can
we
do
about
this
and
there's
been
research
on
it?
A
There's
been
new
programming
languages
developed
internally,
but
nothing
has
quite
worked
out,
but
we
think
that
we
found
a
language
that
potentially
could
get
us
at
least
quite
far,
into
our
journey
of
trying
to
get
that
70%
number
reduced
down
and
that
language
is
rust
and,
of
course,
here
what
I'm
preaching
to
the
choir
right,
you're
at
a
rust
meetup.
You've
probably
heard
about
a
lot
of
these
things
before
you
understand.
A
Probably
that
rust
is
a
memory
safe
systems,
programming
language.
It
can
do
a
lot
of
things
if
C++
can
do,
but
it
can
do
it
in
a
way
that
is
memory
safe.
So
you
can't
have
these
exploits
so
that's
great
you're,
all
more
or
less
sold
here
right,
so
we're
gonna
skip
over
that
part
and
we're
gonna
get
to
the
actual
hard
part
of
it,
which
is
not
convincing
people
that
that
rust
is
a
great
language
that
should
be
at
least
looked
at.
The
real
issue
is
the
issue
of
adoption.
A
It's
very
different
to
go
from.
Rusts
is
a
cool
language
that
I
like
to
use
on
the
weekend
too.
Rust
is
a
language
that
powers
one
of
the
most
used
operating
systems
in
the
entire
world
or
rust,
is
a
language
that
powers
our
billion-dollar
business.
These
are
questions
that
have
to
be
answered
over
and
over
again
with
many
different
people.
A
So
before
we
get
into
that,
we
should
talk
a
little
bit
about
how
languages
get
adopted
and
a
problem
that
doesn't
really
get
talked
about
when
we
talk
about
new
languages
and
the
way
that
you
can
think
of
it
most
clearly,
I
think
is
this
right
here
you
have
costs,
and
can
anybody
read
what
it
says
down
below
yeah?
It's
really
hard
right.
Those
are
the
benefits
and
you
wouldn't
notice,
but
the
benefits
are
much
bigger
than
the
costs,
but
you
can't
read
them.
You
can't
see
them.
A
So
what
are
you
gonna
do
and
that's
really
the
fundamental
issue
that
we
have
here.
You
have
cost-benefit
analysis.
You
can
determine
do
the
benefits
of
adopting
this
language
exceed
the
costs
that
come
with
it.
But
the
problem
is
that
the
costs
that
come
with
adopting
a
new
language
are
very
easy
to
measure
and
very
easy
to
understand.
You
have
to
hire
new
people.
You
have
to
bring
that
that
language
into
your
build
system.
You
have
to
interrupt
that
language
with
existing
code.
You
have
to
make
sure
that
existing
tooling
works
with
that
language.
A
Now,
if
you're
an
element
easiest,
you
might
say
that
I'm
much
more
productive
than
I
am
in
JavaScript
I
write
fewer
bugs,
but
these
are
really
hard
to
actually
quantify
and
so
oftentimes.
What
happens?
Is
you
end
up
talking
anecdotally,
talking
about
how
you
feel
when
you
use
the
language
which
I
know
as
a
programmer,
these
things
really
matter
they're
important,
but
when
you're
talking
to
somebody
who
runs
a
business
and
who
has
to
make
kind
of
a
reel
at
the
end
of
the
day,
dollar
and
cents
actual
decision
about
these
things?
A
Frankly
and
unfortunately
they
don't
really
care,
and
you
know
what
I
can
understand
that
right.
You
can't
really
transport
your
feelings
of
how
this
language
makes.
You
feel
when
you
write
code
to
this
business
person
who
is
making
the
decision
and
that's
fair
enough,
okay,
but
this
is
what
makes
the
rest
more
adoptable
actually.
Is
that
the
problem
that
we
saw
before
of
memory
memory,
vulnerabilities
and
things
like
that
is
a
problem
that
rusts
addresses
we've
already
seen
that
we
have
kind
of
dollar
and
cents
figures
attached
to
this.
A
So
if
you
can
go
into
a
company
and
say
we're
going
to
get
rid
of
a
thing
that
it's
costing
you
and
your
customers
billions
and
billions
of
dollars
a
year,
that's
a
pretty
easy
argument
to
make,
and
because
of
that,
you
end
up
with
a
picture
more
like
that,
where
the
benefit
is
clear
and
it's
much
bigger
than
the
costs
are,
and
that's
roughly
where
we
find
ourselves
today
with
rust
at
Microsoft,
although
we're
still
at
the
very
early
parts
of
our
journey.
So
the
conjecture
we
have
is
four
security.
A
Critical
software
C++
is
no
longer
acceptable,
and
the
bet
that
we
have
is
that
rust
allows
us
to
write
performance
security,
critical
components
safely.
So
then
we're
done
right,
but
of
course
what
this
means
is
not
rewriting
the
world.
We
have
a
whole
bunch
of
things
that
we
need
to
pay
attention
to
as
we
go
along.
If
we
started
today
trying
to
rewrite
every
single
line
of
C++
that
exists
it
inside
of
Microsoft,
we
would
probably
be
done
in
20
years
and
of
course,
in
that
time
we're
going
to
go
out
of
business
right.
A
A
You
get
a
built-in
build
system,
testing
system
right
out
of
the
box,
but
if
you
have
a
build
system,
that's
thirty
years
old
and
is
meant
to
build
an
entire
swath
of
C++
code
along
with
other
languages,
bringing
that
bringing
cargo
into
that
system
doesn't
normally
work
and
that's
an
issue
that
that
we
have
to
address
the
next
one
is
tooling.
We
have
a
whole
bunch
of
tooling
that
is
meant
to
address
specific
things
inside
of
visual
C++
code.
A
That
might
work
with
LLVM
might
work
with
rust,
but
sometimes
it
doesn't
and
it
costs
time
and
money,
obviously
to
get
those
things
to
work,
and
the
next
one
is
is
interrupts
you,
you
have
existing
code,
you
want
to
take
that
rest
code
and
basically
embed
it
inside
of
your
existing
code.
Is
your
rest
code
able
to
even
talk
to
your
existing
code?
What
does
that
look
like
if
it's
a
flat,
C
API
that
you're
talking
to
it's
pretty
straightforward,
pretty
easy,
albeit
it's
unsafe,
and
you
have
to
worry
about?
A
How
are
you
going
to
mitigate
your
safety
issues
there?
You
might
end
up
in
the
same
situation
you're
trying
to
get
away
from,
but
if
it's
C++
it's
much
harder,
how
do
you
in
interact
with
a
heavily
templatized
C++
class
from
rust?
These
are
questions
that
are
not
really
answered
and
then,
of
course,
there's
they're,
just
kind
of
weird
and
strange
things
that
happen
when
you're
working
at
a
large
company.
A
What
does
that
look
like?
That
might
mean
trying
to
build
rusts
using
C++
and
there's
the
the
Umrah
c
project?
That
is
a
russ
compiler
built
in
C++,
and
if
we
have
a
trusted,
C++
toolchain,
you
can
build
that
that
the
Russ
compiler
with
that
trusted
tool
chain
and
then
take
it
up
to
the
latest
version.
A
We
built
this
thing
and
we
can
promise
you
that
nobody
has
injected
malicious
code
into
it,
and
that's
that's
something
that
you
don't
normally
need
to
worry
about,
but
when
you're
adopting
a
new
language
at
the
scale
you
have
to-
and
that
brings
me
to
the
the
next
and
final
point
and
that's
adoption
from
the
other
perspective.
So
yes,
I
work
at
Microsoft,
but
I
also
am
an
avid
rust
user
and
an
enthusiast
and
somebody
who
enjoys
being
a
part
of
this
community
and
I
don't
want
the
adoption
of
rust
at
Microsoft
to
ruin.
A
So
what
are
some
of
the
challenges
that
we
face
right?
We
face
a
challenge,
for
instance,
of
governance,
there's
a
real
challenge
of
governance.
If
you
have
large
companies
getting
involved
in
here,
they
probably
want
some
sibilance
of
stability
in
the
language,
and
what
does
that
mean?
Well,
the
temptation
for
some
large
companies
might
be
to
grab
on
and
try
to
take
control,
but
that
would
in
some
ways
kind
of
ruin
what
we've
built
up
as
the
rest
community,
an
open
community
community
that
collaborates
together.
A
A
When
you
have
a
whole
bunch
of
what
I
call
reluctant
row
stations
coming
and
people
that
are
using
the
language,
not
because
they
love
it,
not
because
it's
fun
not
because
they
do
it
as
a
hobby
in
their
free
time
or
they
enjoy
working
on
the
compiler
or
an
open
source
library,
but
because
their
boss
told
them
to
and
they'd
much
rather
be
using
some
other
language,
and
they
have
to
use
this
stupid
language
with
a
crab.
Why?
A
How
does
that
change
our
community
when
we
have
people
who
are
are
less
willing
to
play
along
with
the
rules
of
the
community?
How
do
we
make
sure,
as
the
community
that
we
can
safeguard
what
we've
built
up
over
time
and
continue
and
make
sure
that
it
continues
to
be
what
it
has
been
in
the
past
so
that
so
there
are
challenges
on
both
sides
challenges
to
Microsoft
as
a
large
company
trying
to
adopt
a
new
language
that
can
really
have
clear
benefit
and
also
challenge
to
us,
as
as
the
rest
community.
A
How
do
we
make
sure
that
we
build
up
and
continue
to
foster
a
community
that
plays
well
with
these?
These
software
giants,
because
we
want
them
to
be
able
to
use
it,
we
want
them
to
be
able
to
contribute
back.
We
want
them
to
be
able
to
to
participate
in
the
community,
but
we
also
want
to
make
sure
that
with
that
power
they
don't
come
through
and
just
ruin
everything
for
us,
and
so
that's
the
challenge
that
we
have
ahead
of
us
today.