►
From YouTube: Philly ETE 2016 #40 - Rust in Production - Steve Klabnik
Description
Rust is a systems programming language from Mozilla that focuses on safety, speed, and concurrency. Rust reached 1.0 a year ago, and so there’s a question everyone is asking: how has 1.0 tested in production? Is the language “ready” yet? In this talk, Steve will give an overview of Rust’s value proposition, focusing on examples and anecdotes from companies using Rust in production today.
A
Hi
everyone,
its
11:30,
so
I'm
gonna
get
started.
My
name
is
Steve
I
work
on
the
rust
project
at
Mozilla.
I'm,
not
gonna,
talk
about
me
a
whole
lot
today,
because
that's
boring
I'm
here
to
talk
to
you
about
rust
in
production.
So
this
is
not
really
an
introduction
to
the
language,
although
I'm
gonna
start
off
by
showing
a
little
bit
of
stuff
about
the
language
who
here
is
actually
used
rust
before
just
so
I
get
a
big
idea
cool.
A
So
some
of
this
might
be
a
little
bit
of
review
for
some
of
you,
but
not
too
much
so
first
of
all,
I'm
gonna
talk
about
what
rust
is
itself
because
part
of
the
part
of
the
question
here
about
like
rust
in
production
is
what
does
rust
actually
offer
like.
Why
would
I
want
to
use
rust
in
production?
So
I'm
gonna
talk
about
that
stuff
first
and
then
there's
actually
a
sort
of
an
interesting
question,
which
is
what
actually
is
production
use.
A
Okay,
so
rust
we
described
rust
as
a
systems,
programming,
language
that
focuses
on
safety,
speed
and
concurrency,
and
the
big
problem
with
words
is
that
nobody
knows
what
they
actually
mean.
So
all
of
those
those
four
words
that
I've
bolded,
which
this
font
is
not
that
great
for
bolding
actually
I
probably
are
this
typeface-
is
not
that
great
for
building
so
systems,
safety,
speed
and
concurrency
are
the
important
parts
of
this.
This
thing
so
I
want
to
talk
about
what
those
four
things
mean,
because
those
mean
different
things
to
like
everyone.
A
So
the
first
is
systems
programming
and
this
term
is
incredibly
ridiculously
overloaded,
a
ton
of
people-
and
this
is
a
particular
definition
that
I
really
like-
and
this
was
coined
by
Yehuda
Katz
as
far
as
I
know,
and
that's
when
the
details
matter
so
systems
programming
is
any
time
when
you
need
to
care
about
the
details.
I
come
from
the
Ruby
world
previously,
and
one
of
the
things
that
we
really
commonly
say
in
Ruby
land
is
like
Ruby
is
slow,
but
that
doesn't
matter
because
the
network
is
the
bottleneck.
A
A
That
means
that
Ruby
is
good
for
certain
kinds
of
things,
and
so
rust
is
the
kind
of
language
where,
if
you
need
control
over
any
sort
of
aspect
of
your
program
or
execution,
rust
will
give
that
to
you
and
so
specifically
a
lot
of
the
reasons
that
people
reach
for
a
language
that
gives
them.
This
kind
of
control
is
on
these
kinds
of
details,
so,
for
example,
I
need
to
deal
with
exactly
when
my
memory
is
allocated
or
D
allocated.
Our
garbage
collector
is
too
inefficient
for
my
use
case.
A
I
need
to
be
concerned
about
the
exact
memory
layout
of
what's
going
on.
This
is
really
important
for
our
performance,
even
as
computers
get
faster
and
faster
cache
is
still
a
thing
being
able
to
fit
your
data
into
l1.
Cache
is
like
significantly
useful
for
speeding
things
up.
Making
sure
that
things
can
be
vectorized
is
really
really
important,
so
I'm
having
control
over
memory
layout
is
definitely
important
for
performance
in
general,
but
also,
generally
speaking,
like
control
and
performance.
A
Go
hand-in-hand
so
that's
like
a
big
reason
why
people
care
about
these
sort
of
details
and
then
just
general
sort
of
determinism,
I'm
gonna
click
on
this
little
link.
We
have
this
really
cool
thing
called
the
playpen
I'm
gonna
close
my
Twitter
tab,
so
I'm
gonna
show
you
a
teeny
little
bit
of
rest
code.
This
is
a
really
cool
plate.
A
Rustling
gorg
is
a
website
where
you
can
type
in
rust
code
and
then
hit
run,
and
then
it
will
run,
and
you
can
also
like
see
the
assembly
that
it
generates
and
you
can
share
this
with
other
people
and
stuff.
So
it's
just
one
example
of
like
how
this
works
here.
Let
me
make
this
teeny
teeny
a
little
bigger,
but
it's
not
really
about
the
code
that
much
so
one
more
smaller.
A
Okay,
so
I
have
a
structure
here,
that's
a
point
and
it's
got
an
X
and
a
Y
that
are
both
32-bit
integers
and
then
in
my
main
function.
I
make
a
new
point
called
origin
which
has
X&Y
set
to
0,
because
that's
what
the
origin
point
is
about
and
then
I
move
that
point
onto
the
heap
by
using
the
Box
new
construct.
So
the
things
I
want
to
point
out
about
control
in
this
kind
of
example
are.
A
This
is
a
structure
in
the
sense
that
I
can
know
for
sure
that
this
will
take
up
exactly
two
32-bit
integers
worth
of
memory.
There's
no
extra
metadata!
There's
no
like
object
here,
no
like
V
tables,
none
of
that
kind
of
stuff
when
I
declare
origin
in
this
way
by
just
declaring
a
point,
it
is
stack
allocated
by
default
instead
of
heap
allocated
by
default.
So,
like
everything,
is
always
on
the
stack
and
I
need
to
use
something
like
a
box
if
I
want
to
explicitly
heap
allocate
things.
A
Furthermore,
I
know
that
whenever
the
main
function
is
over
and
these
two
variable
bindings
go
out
of
scope,
that
is
exactly
when
this
memory
will
be
de-allocated.
So
there's
no
garbage
collector
here
we're
using
the
c++
people,
call
this
ra
íí-,
which
is
like
a
terrible
acronym
I
think
so
we
sort
of
like
say
ownership
and
borrowing.
But
again
this
is
not
really
rust
tutorial.
My
point
is:
is
that
like
everything
here
is
deterministic
and
I
can
tell
you
exactly
how
much
memory
it's
going
to
use
in
what
way
it's
going
to
use
it?
A
A
Gonna
talk
about
this
a
lot
later
and
the
case
studies
is
that
another
thing
that
system
style
programming
gives
you
is
playing
nice
with
other
languages,
so
use
case
this
monk
becoming
incredibly
common
in
the
rust
world
is
putting
rust
inside
whatever
other
language
you
are
already
using,
and
if
you
have
a
language
that
does
not
give
you
that
degree
of
control
say
you
have
a
language
that
is
garbage
collected.
This
rust
is
not
garbage
collected.
A
Why
that's
a
viable
and
interesting
option
in
the
case
study,
stuff,
okay,
so
that's
system
stuff!
Next
up
is
safety,
and
this
is
a
thing
that
is
always
brought
up
when
it
comes
to
rust,
and
it's
also
something
that's
like
tough
and
the
reason
that
it's
tough
is
from
the
like.
Basically,
marketing
is
hard
so
from
a
programming
language
Theory
perspective.
This
is
a
part.
That's
interesting
to
rust,
but
for
people
that
aren't
programming
language
theory
nerds.
A
This
is
a
part
that
a
lot
of
people
don't
necessarily
like
intuitively
understand
why
they
need
this
particular
thing
and
what
we
guarantee
around
safety,
but
the
biggest
difference
that
rust
makes
is
that
is
a
safe
systems
language.
So,
in
this
particular
case,
what
we
mean
by
safety
is
memory
safety.
So,
even
though
rest
has
no
garbage
collector
at
compile
time
rust
guarantees
that
you
will
have
no
segmentation
faults.
A
Let
me
show
you
these
two
things:
okay,
so
here's
our
point
again
and
then
there's
this
main
function
called
won't
work
and
what
this
function
does
is
I
can't
scroll
a
little
bit
farther.
So
it's
still
gonna
be
on
the
bottom.
You
see
if
I
get
there,
we
go
okay,
so
this
function
tries
to
allocate
a
point
on
the
stack
and
then
return
a
pointer
to
it,
and
so
this
is
a
very
trivial
example
of
what's
called
a
dangling
pointer.
A
So
if
I
wrote
this
code
in
C,
the
origin
is
going
to
go
out
of
scope
at
the
end
of
the
function
and
it
will
disappear.
So
now
this
pointer
is
pointing
to
invalid
memory
and
so
accessing
that
pointer
is
now
undefined.
Behavior
and
all
sorts
of
bad
things
can
happen
or
might
not
happen
like
that's
actually,
okay,
so
part
of
the
problem
with
undefined
behavior
is
that
it
might
do
something
reasonable
for
a
while
and
then
only
eventually
later
do
something
terrible.
A
You
just
have
no
idea,
but
if
we
try
to
actually
run
this
rust
will
complain,
and
in
this
particular
instance,
this
gives
us
an
error
that
is
I'm
going
to
shrink
this
a
little
bit.
It
says
this
functions.
Return
type
contains
a
borrowed
value,
but
there's
no
value
to
be
borrowed
from,
and
that
is
basically
saying
this
is
a
dangling
pointer.
It
uses
a
little
bit
of
jargon
that
I
have
not
fully
explained
to
you
because
again,
this
is
not
about
being
a
rust
tutorial.
A
But
my
point
is
this
kind
of
unsafe,
like
code,
just
straight
up,
does
not
compile
so
you
have
to
actually,
if
it
could,
if
it
compiles
it,
works
is
a
little
too
strong.
I,
like
people
like
to
use
that
phrase,
but
that's
not
always
true.
Software
has
bugs
the
rest.
Compiler
is
not
perfect.
Static.
Analysis
is
inherently
conservative,
but
the
eret
there's
a
significant
amount
of
work
that
is
required
in
order
to
get
through
I'm
gonna
click
on
this
other
one
through
the
compiler
and
make
sure
that
code
works
properly,
I'm,
not
in
presenter
mode.
A
This
does
not
actually
do
the
right
thing.
Ok,
so
here's
another
example
of
rust
statically
preventing
a
problem
at
compile
time.
So
if
I
have
a
vector
V
that
is
mutable-
and
it
has
one
two
three
four
five
in
this
list,
if
I
loop
through
each
element
in
the
vector
getting
references
to
them
so
I'm
getting
a
reference
to
the
first
element
in
the
second
element
of
third
element
and
then
line
five
they're
prints
out.
This
element
is
e.
This
works,
but
line
six
is
the
problem,
so
V
dot,
clear,
empties
the
vector.
A
So
if
I
modify
this
vector
while
I'm
looping
over
it,
that
means
that
all
of
the
other
indices
are
going
to
be
invalid
and
that's
a
problem.
Different
languages
handle
this
problem
differently.
It
depends
if
you're
using
Java
Java
will
say.
Hopefully
we
will
throw
a
concurrent
modified
exception,
but
it's
not
actually
guaranteed.
If
you
run
this
in
Ruby,
it
will
give
you
what
is
intuitive
to
people
that
understand
Ruby's
GCC,
but
not
intuitive
to
humans
results.
A
A
Error-
and
it
says,
cannot
borrow
V
is
mutable
because
it's
already
borrowed
is
immutable
and
this
whole
big
error
message
which
basically
points
out:
hey
you're
already
referring
to
this
vector
here,
so
you
can't
also
mutate
it
while
it's
being
referred
to
so
again,
this
is
like
a
static,
compile
time
analysis,
there's
no
runtime
overhead
for
doing
this,
but
it
catches
a
lot
of
errors,
and
both
of
these
two
examples
are
really
trivial
versions
of
this
problem.
One
of
the
problems
are
trying
to
show
off.
A
So,
ok
and
and
I
guess
this.
This
also
then
ties
into
the
next
one,
which
is
speed
so
you'll
also
notice.
That
speed
is
the
like
second
goal:
it's
safety
and
then
speed.
So
rust
wants
to
be
extremely
fast
and
it
does
for
reasons
that
I'll
get
into
a
second.
But
the
point
is:
is
that
we
always
do
the
safe
thing
first
and
the
theoretical
speediest
thing.
Second,
but
through
the
wonders
of
programming,
language,
design
and
LVM
and
optimizing
the
pilers,
it
turns
out
that
the
safe
thing
is
often
also
the
fastest
thing.
A
A
Basically,
it
is
a
is
really
really
important
to
understand
that
when
you
do
micro,
benchmarking,
I
think
one
I
favor
descriptions
of
the
benchmark
game,
but
those
of
you
who
are
not
familiar,
it's
basically
a
collection
of
10
or
15
programs
that
people
submit
things
to,
and
then
there
on
this
chart
and
I
think
that
it's
important
someone
described
it
as
like.
It's
really
testing
the
speed
of
whoever
has
the
most
free
time
on
their
hands
for
writing
the
benchmarks
and
then
also
in
the
case
of
the
benchmarks
game.
A
But
the
important
part
is
not
specifically
like
that.
So
on
this.
In
this
instance
for
examples,
there's
columns
that
indicate
which
programming
languages
the
leftmost
is
the
fastest
and
the
rightmost
is
the
slowest
the
left
is
GCC
with
C.
The
second
one
is
rust
and
the
third
one
is
C++
with
G
+
+.
So
the
important
part
to
me
here
is
not
like,
strictly
speaking,
that
rust
is
beating
C++.
A
But
this
sort
of
points
out
the
degree
to
which
we
are
able
to
optimize
Russ
code
and
the
degree
to
which
we
have
made
language
decisions
that
do
not
inhibit
optimizations,
because
Russ
being
very
very
fast,
is
really
important
and
in
our
production
users,
I
will
talk
a
little
bit
specifically
more
about
why
but
yeah,
and
so
this
is
sort
of
just
a
general
kind
of
rule.
Russ
should
be
roughly
the
same
speed
of
c
or
c++,
if
not
as
a
bug.
A
There
are
lots
of
bugs
so
like
please
file
them
if
you
use
rust
and
find
them,
but
this
is
sort
of
the
like
mental
takeaway
in
terms
of
thinking
about
language
performance
that
I
want
you
to
have
in
your
brain.
Is
that
rusted
in
that
class
of
languages
generally
speaking,
okay
and
then
finally,
concurrency
is
the
last
part
of
this
I'm
not
going
to
show
any
code
for
this,
because
this
is
complicated
and
I
promise.
A
This
would
not
be
an
introduction
to
Russ
talk,
but
what's
interesting
is
that
concurrency
sort
of
it
was
always
a
sort
of
core
feature
of
rust,
but
is
now
actually
serviced
through
the
type
system,
as
opposed
to
like
the
language
itself,
which
is
interesting
and
complicated
and
is
also
a
whole
talk
that
I
give
entirely
separately
of
this.
So
to
give
you
the
summary,
there's
this
slogan
called
shared
mutable
state
is
the
root
of
all
evil.
A
I'm
sure
you've
all
heard
of
this
problem,
but
what's
interesting
about
this
particular
quote-
is
that
most
languages
interpret
this
as
being
mutable
state
as
the
root
of
all
evil,
but
it
turns
out
like
mutable
state,
is
not
actually
the
problem.
You
can
also
look
at
this
quote
and
take
it
as
shared
stage
as
the
root
of
all
evil
and,
like
that's
not
actually,
strictly
speaking,
the
problem
either.
The
problem
is
like
shared
and
mutable
at
the
same
time
as
the
root
of
all
evil.
A
So
if
I
have
immutable
data
and
I
share
it
across
n
threads,
that's
totally
fine,
because
they're
all
gonna
read
the
same
value
every
single
time.
If
I
only
have
one
thread
accessing
a
piece
of
data
and
it's
immutable,
that
is
totally
fine,
because
no
other
threads
are
going
to
be
able
to
observe
the
problem
here
and
so
most
languages
deal
with
this
problem
by
saying,
like
okay,
to
deal
with
concurrency
we're
gonna
make
everything
immutable
and
then
try
to
figure
out
how
to
make
that
perform
in
a
reasonably
acceptable
way.
A
What
Russ
does
is
a
little
more
complicated
in
some
ways,
but
also
not,
and
so
basically
rust
will
let
you
share
a
mutable
state
as
much
as
you
want
and
it
won't
let
you
share
mutable
state
unless
you
specifically
use
some
sort
of
concurrency
primitives
that
it
provides
you
safety.
So
Russ
does
not
take
the
position
that
like,
for
example,
shared
memory.
Concurrency
is
bad.
We
just
have
a
type
system
by
which
you
cannot
do
shared
memory
concurrency,
unless
you
put
it
behind
a
mutex.
A
The
type
system
will
actually
not
let
you
so
you
can't
accidentally
stumble
across
these
kinds
of
shared
mutable
errors
and
again
the
way
in
which
we
accomplish.
That
is
the
thing
I
would
love
to
tell
you
about,
but
is
not
what
this
talk
is
actually
about,
but
the
important
part
is
that,
like
concurrency
is
very
important
to
rest
and
again
this
is
sort
of
a
little
miniature
theme
you
may
have
noticed.
A
I
mentioned
that
it'll,
give
you
a
compile
time
errors
about
concurrency,
and
that's
actually
true
and
kind
of
mind-boggling
at
first-
is
that
this
is
not
like
I
run
my
rust
program,
a
bunch
and
monitor
it
and
then
check
the
errors
that
come
out.
This
is
at
compile
time.
The
rust
compiler
will
say:
hey.
You
are
sharing
this
data
between
two
threads
with
a
mutex
that's
wrong.
A
So
anyway,
it's
really
really
cool
to
have
now
when
I
write,
Ruby
code,
I
am
terrified
that
I'm
doing
the
wrong
thing,
because
I'm
so
used
to
the
compiler
checking
everything
for
me
that
I'm,
just
like
I'm
allowed
to
do
whatever
I
want,
and
that's
really
scary,
I
also
just
turned
30
and
I'm
slowly
becoming
a
real
adult.
So
maybe
that's
part
of
it
as
well.
A
Okay
and
then
so.
The
last
thing
I
want
to
mention
before
I
start
getting
into
the
production
aspect
of
this
talk
just
theoretically
the
point
there's
this
tension
that
I
have
not
totally
been
able
to
resolve
in
my
like
marketing
rust
to
people
efforts,
and
so
I
want
to
just
present
you
with
this
conundrum.
So
you
can
think
about
it
yourself.
A
A
Otherwise,
I
also
call
this
the
Diesel
objection.
So
my
friend
Shawn
writes
this
forum
called
diesel
for
rust
and
he
gets
mad
at
me.
Every
time.
I
talk
about
rust,
being
low
level
because
he's
like
that's
totally
irrelevant
for
my
use
case.
I
do
not
care
about
this.
Shawn
is
a
database
guy,
and
so
he
is
writing
an
ORM
in
rust,
and
so
this
is
some
rust
code
here
on
the
left.
The
idea
is
that
it's
sorting,
a
certain
number
of
versions
that
belong
to
a
crate,
rust
package
is
called
a
crate.
A
A
They
all
basically
boil
down
to
types
are
really
cool
type
systems.
Let
you
do
a
lot
of
stuff,
but
so
he
is
always
like.
You
should
not
talk
about
the
low-level
aspects.
You
should
talk
about
the
expressiveness
of
the
type
system
and
how
it
lets
you
like
double
check
your
work
and
all
these
other
things
so
he's
always
think
of
with
that
respect,
but
anyway,
so
so
I'm
sort
of
of
two
minds
about
this.
A
A
I
think
it's
really
important
that
you
understand
that
is
X
production,
ready,
there's
a
question
that
needs
additional
context
in
order
to
be
answered.
Now,
it's
my
like
pretend
English
major
background
to
say.
Well,
everything
is
contextual,
of
course,
but
like
I
think
that
this
is
really
important,
that
this
particular
question
like
when
I
was
writing.
This
talk,
I
was
setting
out
to
answer
the
question
like
is
rust,
production
ready
and
my
answer
is
like
yes,
but
it
depends,
which
also,
incidentally,
is
I.
A
Think
the
sign
of
a
good
engineer
is
that
you
always
need
to
have
a,
but
it
depends
right
like
that's,
because
every
single
thing
has
trade-offs,
so
I,
don't
want
to
present
to
you
like
this.
Talk
is
not
about
like
rust,
is
absolutely
ready
for
everyone,
and
you
should
use
it
today
for
literally
everything
if
I
was
telling
you
that
I
would
be
a
liar
and
deceiving
you
so
who
here
is
familiar
with
this
diagram?
This
is
like
an
old
old
thing.
A
A
If
not,
this
was
an
old
business
book
about
how
businesses
and
technologies
get
adopted,
and
basically
the
idea
is
that
if
you
take
the
subset
of
users
of
your
thing,
they
fall
underneath
this
curve,
and
so
we
can
split
the
curve
up
into
5
1
2,
3,
4,
5,
yeah,
5
5
different,
like
groups
of
people
basically,
and
that's
all
good
and
fine.
But
the
thing
about
the
book
is
that
there's
this
chasm
there,
hence
crossing
the
chasm
and
what
the
chasm
represents.
A
Basically
is
that
there's
no
actual
guarantee
that,
just
because
some
early
adopters,
like
your
thing,
your
thing
will
actually
get
used
by
a
significant
number
of
people,
because
there
are
a
lot
of
technologies
and
businesses
and
products
and
whatever
else
you
want
to
apply
this
to,
that
will
have
a
lot
of
people
who
are
very
enthusiastic
at
the
beginning,
but
will
fail
to
reach
sort
of
the
mass
market
or
the
mainstream
market.
As
this
particular
version
of
this
chart
displays
and
the
reason.
Why
is
that?
A
No
js'
sucks
is
because
one
of
the
parties
involved
is
in
the
conservative
part
of
this
when
it
comes
to
this
particular
technology
and
the
other
person
is
part
of
the
visionary
section
and
so
they're
actually
talking
past
each
other,
because
they
don't
even
have
the
same
goals
in
the
first
place.
So
I
think
this
is
a
really
important
concept,
but
anyway,
I
think
that
a
lot
of
people
when
they're
talking
about
is
it
production-ready
is
what
they
actually
mean
is.
A
A
They
want
to
wait
until
after
the
thing
is
successful,
but
not
too
long
after
because
if
it's
too
long
after
it's
not
like
cool
anymore,
so
you
want,
like
the
benefit
of
it,
being
like
just
freshly
over
the
chasm,
but
not
like
so
much
that
those
boring
conservatives
and
skeptics
might
think
that
you've
made
a
right
decision
instead
of
a
rash
decision.
Right
like
we
all
want
to
be
a
certain
degree
of
cool
and
so
to
me,
I
think
that,
especially
when
it
comes
to
something
like
a
programming
language
or
an
open-source
technology.
A
The
chasm
is
the
question
of.
Is
this
ready
for
production
or
not?
And
so
there
are
certain
people
who
will
start
using
something
in
production
when
it's
on
the
left
edge
of
the
chasm
and
then
the
goal
is
to
get
enough
of
them
to
start
using
in
a
production
that
it
has
reached
the
right
end
of
the
chasm
and
is
now
crossed.
It's
like
I
think
that's
the
actual
like
this
is
the
test,
and
so
of
course,
obviously
the
follow-up
is
I.
A
Think
that
Russ
is
at
this
part
of
the
chasm
you
may
or
may
not
agree
or
disagree
with
me
and
that's
fine,
but
I.
Definitely
don't
think
that
we
are
like
in
the
middle
yet
at
all,
but
I
think
that
rust
is
sort
of
in
this
point
where
we
are
either
in
the
chasm
or
just
barely
on
the
other
side
of
the
chasm
and
the
reason.
Why
is
that
we
do
have
a
number
of
significant
organizations
using
rust,
and
so
I
would
like
to
tell
you
about
them.
A
So
here
is
my
set
of
case
studies.
I
have
four
specific
examples
to
share
with
you
of
varying
degrees,
of
production
use
of
rust,
and
this
is
my
this
is
my
first
one.
This
is
a
logo
of
a
company
called
made
safe.
They
do
this
thing
that,
depending
on
how
you
look
at
it,
it's
either
like
a
way
to
save
your
files
on
hard
drives
securely
or
a
cryptocurrency,
based
on
how
you
look
at
it.
A
It's
complicated
but
like
I,
actually
don't
care
that
much
specifically
at
what
that
product
does
I
do
care
about
the
experience
they
had
when
using
rust
so
and
they
are
also
like
they've
received,
like
20
million
dollars
in
VC
funding
and
there's
TechCrunch
articles
and
whatever.
If
you
like
care
more
about
this
topic,
I'm
learning
what
they
did,
but
what
I
think
is
interesting.
Is
there
a
particular
story
so
made
safe
was
a
C++
shop.
A
They
rewrote
it
in
rust
and
it
got
a
lot
smaller,
but
like
the
problem
with
stories
like
that,
is
that
every
rewrite
ever
always
gets
smaller,
because
you
like
know
the
problem
better
and
you
can
get
rid
of
all
the
vestigial
stuff
that
you
weren't
using
and
all
those
kinds
of
things.
And
so
what
I
like
about
this
particular
story?
Is
they
decided
to
do
sort
of
like
a
version
two
and
that
turned
out
to
be
the
same
amount
of
functionality,
but
in
75,000
lines
of
C++.
A
A
Your
crates
between
people
like
I,
could
see.
You
know,
I,
don't
know
I
like
it.
It's
got
very
like
blue-collar,
like
dock
worker
feel
to
it,
but
the
important
part
about
this
is
that
in
that
seventy
five
thousand
lines.
The
reason
that
is
only
that
small
is
because
they
found
a
number
of
open
source
packages
that
were
already
available
to
use
for
them.
So
that's
not
counting
the
lines
of
code
of
the
packages
they
used.
A
A
I
didn't
do
my
normal
little
spiel
about
I
like
to
talk
about
there's
three
communities
that
sort
of
come
to
rest,
there's
systems,
programmers,
the
functional
programmers
and
the
scripting
programmers
all
of
them
bring
something
to
the
table
on
all
of
them
like
get
something
out
of
rust.
The
the
big
thing
with
the
scripting
people
who
I
nominally
consult,
might
consider
myself
a
part
of
what
we
bring
to
the
table
is
a
respect
for
user
interfaces
and
making
tools
that
work
well.
A
So,
like
a
couple
years
ago,
you
would
still
use
make
files
to
write
rust
code
and
then
a
pile
of
us
rubyists
joins
and
we're
like
we
like
bundler
and
NPM,
and
these
kinds
of
tools
we
want
one
of
these
for
rust
and
all
the
systems
people
said.
Okay,
you
cute
kids,
do
your
little
kid
thing
will
be
here
like
adults,
writing
make
files,
and
then
we
wrote
cargo,
and
then
they
went.
Oh,
my
god,
why
am
I
still
using
make
files?
A
So
what
cargo
lets
you
do
again
is
like
if
you're
from
the
system's
world
is
sort
of
new,
but
if
you're
from
the
Ruby
world
or
the
JavaScript
world,
it
is
very
boring.
Basically
there's
this
website
crates,
duh
bio,
and
it
gives
you
these
lists
of
packages.
I
think
that
I
made
another
no
I
did
not
it's
basically
like
all.
You
need
to
do
to
get
a
dependency
in
the
rust
world
is
to
add
one
line
of
configuration
to
your
config
file.
I
supposed
to
have
questions
that
end,
but
I.
A
Guess
if
you
have
something
that's
relevant
right
now,
I
can
do
thing
it's.
So
the
question
is
because
I
have
a
microphone
as
if
cargo
has
left
pad.
The
answer
is
it
has
three
left
pad
packages
now
three
weeks
ago
it
did
not
zero,
it
does
my
partner
actually
works
for
NPM
doing
community
management,
so
this
question
has
been
near
and
dear
to
my
soul
for
the
last
couple
of
weeks
anyway,
the
important
part
is
the
difference
there.
A
I'll
just
shout
that
out
at
the
moment,
cargo
is
immutable,
so
you
can
unpublish
things
so
that
will
not
happen.
The
left
pad
thing
cannot
occur
with
crates
Ohio,
you
can
markup
packages,
no
new
dependencies
are
allowed,
but
it
is
append
only
in
immutable,
so
you
cannot
destroy
the
entire
ecosystem
because
you
get
upset
that
doesn't
work,
but
the
important
part
is
that
by
reducing
the
friction
of
writing
open
source
code
and
sharing
it
with
other
people,
it
happens
a
lot
more
often
I'm
gonna
talk
in
a
minute.
A
Why
this
like
34
million
downloads
number,
is
like
a
little
questionable.
Actually
well
yeah
I'm
getting
into
it
later,
but
it
is
a
lot
it
is.
It
is
actually
that
many
downloads,
but
part
of
that
is
due
to
bots,
but
the
important
part
is
like
we
already
have
4600
crates
in
stock.
I
took
this
screenshot
a
couple
hours
ago,
so
it
should
be
like
roughly
accurate.
There
probably
are
like
3
more
or
something
by
now,
but
even
as
a
relatively
young
language,
because
we
had
this
ecosystem
tooling
available
beforehand.
A
There
is
a
significant
number
of
people
writing
these
packages
and
sharing
them
and
for
all
kinds
of
domains.
So
I
actually
have
a
hobby
project.
That's
the
pitch
is
you
know
JavaScript?
Let's
write
an
operating
system
and
rust
together
that
I'm,
currently
working
on
it's
actually
more
feasible
than
you
would
think
it
turns
out.
It
takes
about
150
lines
of
assembly
to
boot,
up
an
x86
machine,
and
then
you
get
into
rust
code
and
just
write
some
rust,
but
the
important
part
that's
really
cool
is
while
I
am
writing.
This
build
a
rust
OS
tutorial.
A
There
are
actually
packages
on
crates,
dot,
IO
that
are
useful
when
writing
an
operating
system.
So
like
the
idea
that
we
can
like
share
code
when
writing
our
own
hobby
os's
together,
is
like
very,
very
new.
Like
most
of
the
times,
those
kind
of
projects
have
no
sharing
whatsoever
and
again
are
written
entirely
separately,
like
like
there's
a
package
that
lets
you
access
features
if
you're
using
like
a
specific
model
of
x86
64
CPU,
you
can
like
get
the
specific
assembly
like
whatever
shenanigans.
That's
not
the
point.
A
Nowadays,
it's
been
about
a
year
year
and
a
half
I
think
since
they've
done
that
and
they're
like
we
are
already
farther
along
with
our
project,
even
though
we
did
a
rewrite
in
rust,
so
they
were
concerned
about
their
velocity,
but
they
think
that
using
rust
has
actually
made
them
be
able
to
go
faster.
They
specifically
have
this
story
about
one
component:
I
didn't
I,
didn't
find
a
good
quote
about
this,
because
it's
sort
of
long
so
I'll
just
leave
this
slide
up.
A
Will
I
tell
you
it,
but
there's
this
one
particular
conent
component,
that
they
haven't
renamed
crust
since
they
rewrote
and
rust.
It
was
called
something
else
before,
but
it
basically
does
routing
like
IP
routing
packets
to
different
computers
doing
stuff,
and
they
spent
about
six
months
when
they
wrote
the
C++
version.
A
Debugging
memory,
safety
errors
around
random
seg
faults
and
other
things
that
were
occurring
in
their
code
and
they've
never
had
a
seg
fault
in
the
rest
code
ever
they're
like
we
wrote
it
a
weekend
and
now
it
just
works
and
has
worked
forever,
and
so
that's
what
they
mean
by
like
we
are
more
productive
in
rest
than
C++.
Is
this
kind
of
static
analysis?
Shenanigans
means
that
you
don't
spend
hours
and
hours,
debugging
scary,
bugs
later,
basically,
okay
enough
about
crypto
currencies.
A
Let's
talk
about
Dropbox
I,
don't
know
how
many
of
you
have
heard
this
news
that
came
out
relatively
recently,
I'm,
really
glad
that
it
happens
a
couple
weeks
ago.
They
finally
announced
it,
but
there
was
this
story
that
was
going
on
and
wired
specifically
called
the
epic
story
of
Dropbox
exodus
from
the
Amazon
Cloud
Empire,
which
is
a
little
dramatic,
but
I.
Guess
it's
hard
for
magazines
these
days
you
got
a
people
somehow,
but
this
story
was
the
first
public
announcement
about
Dropbox's
use
of
rust
in
production
and
what's
cool
about
it.
A
Today,
I'll
tell
you
about
what
it
is
in
a
second
but
well.
I'll
tell
you
right
now:
okay,
so
basically
Dropbox's
core
business
proposition
is
storing
some
bytes
on
some
hard
drives
somewhere
in
the
cloud
right
like,
and
then
you
want
those
bytes
on
another
computer
and
they
magically
appear
there
through
no
work
of
your
own.
A
They
there's
only
really
been
this
story
so
far,
but
if
you
pay
attention
in
the
coming
weeks,
they're
gonna
be
doing
a
like
12
part
blog
series
about
it
or
something
I
know
marketing,
one
of
them
to
get
the
wired
article
out
before
their
engineers
were
allowed
to
post
a
manage
an
earing
blog
about
the
engineering
stuff.
So
they've
said
that
they're
gonna
have
a
number
of
posts
about
all
the
aspects
of
this
thing,
including
two
or
three
that
specifically
focus
on
the
use
of
rust,
but
I
just
wanted
to
comment.
A
Well,
tell
you
some
of
the
comments
that
they
have
said
about
their
usage
of
rust,
so
about
18
months
use
in
total
in
production,
as
of
December,
stability
has
been
very
good.
In
the
last
six
months,
we've
had
no
issues
of
stability
of
the
compiler,
the
binaries
or
the
standard
library.
Long
story
short.
A
We
have
a
very
short
list
of
minor
grievances
with
the
rest
and
a
very
short
list
of
major
ones,
which
is
basically
build
times,
but
in
general
it's
worked
out
really
well
and
we're
seriously
investigating
writing
more
rust
for
pieces
of
our
infrastructure
at
Dropbox.
So
I'm
like
really
really
excited
that
they
are
happy
with
things
overall.
The
build
times
thing
is
interesting
and
complicated,
but
like
we're
working
on
it,
the
thing
that's
funny
about
build
times
is:
it
depends
entirely
on
what
you
do
that
determines
whether
it's
fast
or
slow.
A
So,
like
I,
hear
some
some
people
say
rust
is
really
fast
build
times
and
then
other
people
say
rust
is
really
slow
build
times.
Dropbox
is
mostly
a
go
shop,
so
any
build
time
is
a
slow
build
time
to
them
and
that
it's
not
to
say
that
their
grievance
is
not
legitimate
but
like
we're
working
on
making
it
I'm
significantly
faster,
but
part
of
the
problem
with
having
a
language
that
does
significant
amounts
of
static
analysis
and
optimization.
A
Is
that
means
build
time
like
fundamentally,
you
can't
escape
that,
but
we
don't
want
it
to
be
a
pain
point,
so
it
is
being
worked
on
but
yeah,
so
they
even
have
a
good
time
and
I'm
glad
about
it.
I
think
this
is
my
stability
slide,
yeah
stability,
so
you
who
to
cats,
who
is
also
a
rust
core
team
member
I,
mentioned
him
earlier
with
his
systems.
Programming
thing
quote:
he
gave
a
talk
yesterday.
That
was
really
fantastic
and
I,
think
it
got
recorded.
A
I
hope
so
so
I
want
to
link
it
to
people
called
stability
without
stagnation.
I
know,
if
any
of
you
saw,
that
particular
talk
and
he
referenced
rust
a
couple
different
times
in
this
talk,
but
basically
I
think
that
rust
is
one
of
the
programming
languages
that
takes
stability
extremely
seriously,
and
this
has
a
number
of
different
components.
One
of
them
is
basically,
we
have
a
and,
with
the
without
stagnation,
part
is
the
interesting
part.
So
stability
does
not
mean
we
never
change.
A
However,
there's
a
number
of
reasons
that
we
actually
believe
that
that
leads
to
stability,
so
I
will
I'll,
give
you
an
example
from
Ruby
world
again,
because
I
am
from
Ruby
and
love
Ruby
and
have
a
ruby
tattooed
on
my
body.
So
I
criticize
it
from
a
place
of
love,
not
a
place
of
anger,
Ruby
releases
on
Christmas
every
year.
A
Traditionally,
that's
the
Ruby
release
day
and
one
of
the
problems
with
having
a
yearly
release
is,
if
someone
proposes
a
new
feature
in
October
you're
looking
at
either
like
we
hurry
up
and
sneak
it
in
or
it's
gonna
last
another
like
year
before
it
gets
in,
and
so
one
of
the
problems
with
having
a
long
release
cycle
is
that
you
feel
this
pressure
right
before
the
release
to
like
get
stuff
in
before
you're
ready
for
it
to
go,
and
so
by
having
frequent
but
smaller
releases.
It's
totally.
A
Okay,
if
a
feature
is
not
going
to
be
ready
for
the
release
on
Thursday,
because
it
will
be
six
weeks
until
the
next
release.
So
it's
totally
fine.
So
this
actually
encourages
us
to
ship
major
things
on
a
longer
scale,
because
we
don't
have
this
pressure
because
releases
are
kind
of
boring,
and
so
there's
that
kind
of,
like
software
engineering
aspects
to
it,
there's
a
whole
host
of
stuff.
A
Again
you
who
literally
talked
about
this
concept
for
an
hour
so
I
don't
want
to
like
use
my
entire
talk
to
talk
about
this
talk
in
general,
but
there's
one
thing
that
he
did
not
talk
about,
because
it's
sort
of
rust,
specific
and
that's.
Why
this
and
a
shout
out
to
crater.
So
remember
that
I
told
you
that
that
34
million
number
was
like
a
little
sketchy.
One
of
the
things
that
we
do
on
a
regular
basis.
Is
we
download
literally
all
of
the
packages
and
try
to
compile
them,
so
we
actually
have
a
tool.
A
So
the
release
is
coming
out
on
Thursday.
The
branch
actually
happened
yesterday
and
we're
currently
in
the
process
of
like
building
the
release
artifacts.
But
before
we
did
the
branch,
one
of
the
things
that
we
did
was
we
took
what
will
become
the
next
release
of
rust
and
we
ran
it
across
literally
every
single
package
in
the
ecosystem
and
determined
that
all
of
them
still
worked.
A
So
we
can
actually
like
guarantee
you
that
when
the
new
version
of
the
language
comes
out,
everything
will
be
fine,
because
we
already
did
it
and
in
the
working
up
to
the
actual
release
like
we
don't
do
it
every
week,
but
we
do
it
on
demand.
Whenever
we
have
a
change
that
we
think
is
like
significantly
suspicious
like
does
it
factor
a
lot
of
compiler
internals
around
the
type
system,
probably
better
double
check
that
we
didn't
break
anything
and
all
this
other
kind
of
stuff.
A
We
also
heavily
test
rust
itself
and
we
actually
do
full
continuous
integrations
so
like
no
commits
lands
on
master
without
having
run
through
a
ridiculous
array
of
tests.
We
actually
have
36
separate
configurations
of
platforms
that
we
build
for
and
on
to
double
check
that
they
all
work
and
on
as
of
last
week
on
every
commit
we
download
the
top
70
of
these
packages
and
check
that
they're,
okay
on
literally
every
commit.
So
we
care
a
lot
about
stability
and
making
sure
your
stuff
doesn't
break.
A
Even
though
we
do
this
sort
of
rapid
release
kind
of
thing,
and
so
that's
why
that
number
gets
a
little
inflated
is
because,
like
we're
sort
of
doing
it
a
lot
but
s3
can
handle
it,
it's
bill
we're
just
tiny
in
the
giant
bucket
of
the
Amazon
Cloud
but
yeah.
So
we
do
a
whole
bunch
of
checking
to
make
sure
these
things.
A
So
we
have
sort
of
rules
about
when
we
are
allowed
to
make
changes
that
would
be
perceived
as
breaking
and
how
all
that
stuff
works,
and
we
on
each
release
we
call
out
like
here
is
a
change
that
you
may
need
to
make
a
small
tweak.
But
basically,
if
it
takes
more
than
five
minutes
to
fix,
it
is
not
considered
acceptable.
It's
sort
of
the
general
rule,
but
statically
typed
languages
make
it
really
really
hard
to
change.
A
Literally
everything
and
even
languages
that
historically
take
breaking
changes
very
seriously,
like
Java
has
a
reputation
for
ever
breaking
your
code,
but
every
Java
release
has
breaking
changes,
they're,
just
so
minor.
You
don't
notice
them.
So
that's
our
goal
is
to
you
should
never
notice
breakage
in
ecosystem.
A
Okay
and
now
I
want
talk
about
skylights,
so
little
slower,
lower
resolution
than
I'd
hoped
for
this
logo.
But
whatever
skylight
is
one
of
our
oldest
production
users
and
probably
one
of
our
first
production
users
overall
and
what
they
do
is
they
are
a
performance
monitoring
tool
for
rails
apps.
So
what
happens
is
if
you
have
a
rails
application?
A
You
gem
install
skylight,
you
sign
up
for
an
account,
you
add
a
your
private
key
or
whatever
to
your
apps
config,
and
then
it
basically
monitors
everything
and
sends
the
data
back
to
their
servers
and
you
get
a
little
web
app
that
you
can
like
check
out
like
these
are
my
slow
pages.
This
is
what's
being
fast
or
slow.
Yada,
yada,
yada,
this
kind
of
stuff,
and
so
what's
interesting
about
skylight,
is
that
it
is
a
rails
app.
A
So
you
need
to
install
a
ruby
gem
to
make
this
thing
happen,
but
that
ruby
gem
is
actually
written
in
rust.
So
this
is
the
embedding
case
that
I
was
talking
about
earlier.
The
initial
version
of
the
skylight
monitoring
gem
was
actually
written
in
Ruby,
but
there
are
two
problems:
one
is
GC
pauses,
+
performance
monitoring
is
complicated.
A
Did
your
app
receive
a
sudden
spike
in
latency
because
a
bunch
of
people
hit
it
or
because
the
GC
decided
to
start
working
while
you're
in
the
middle
of
timing,
I,
don't
know,
etc.
They
were
also
sort
of
memory,
leaks
and
Yehuda,
who
co-founded
tilde,
which
makes
skylight
literally
has
commits
to
Ruby,
and
he
could
not
find
the
memory
leaks
in
that
ruby
program.
So
it's
hard
and
so
due
to
like
the
the
speed
issues
and
the
memory
leak
issues
and
a
number
of
different
things,
one
of
the
other
cofounders
of
a
company
said.
A
And
then
they
said,
maybe
this
Ruby
thing
isn't
so
bad
after
all,
but
then
they
heard
about
rust
shenanigans
and
they
decided
to
try
rewriting
and
rust
said
original
employee.
Who
was
writing
at
sea
was
not
very
happy
about
it
originally,
but
he
eventually
came
around
is
now
one
of
the
most
prolific
contributors
and
the
rest
ecosystem,
generally
speaking,
but
basically
I
have
a
quote,
so
we
ship
rusts
to
redacted
I,
was
talking
with
who
to
last
night
about
this.
A
We
ship
rust
code
to
a
redacted
number
of
customer
servers
and
have
done
so
for
a
couple
of
years.
There
have
been
two
crashes
in
those
two
years.
One
was
due
to
a
bug
and
rust
that
we
fixed
another.
One
was
due
to
some
silly
shenanigans.
The
point
is
not
the
point
is
that
I
can
literally
enumerate
all
the
crashes
they've
had
again.
This
is
like
code
that
is
being
deployed
to
other
people's
servers.
They
do
not
control
under
whatever
kinds
of
conditions,
and
it's
been
super
super
rock-solid.
And
furthermore,
this
is
another
thing.
A
I
think
is
very
interesting
and
another
aspect.
That's
cool
about
rust.
The
employer
wrote
the
original
rust
code
is
left,
but
we
haven't
found
it
tough
to
maintain
even
for
new
employees,
less
rust
expertise.
All
of
the
bug
fixes
to
this
agent
have
been
done
by
someone
who
primarily
writes
JavaScript
and
Ruby.
So
there's
a
number
of
smaller
startups,
so
I
did
not
put
on
this
list
of
production
users,
but
one
of
the
common
things
that
people
bring
up
is
the
rust
compiler
being
so
strict
Meek's
mains.
A
It's
like
a
teaching
tool,
so
I'm
much
more
willing
to
hire
someone
that
is
relatively
more
junior,
because
I
know
the
compiler
will
check
their
mistakes,
whereas
if
I
was
writing
C
code,
I
would
need
to
double
check
literally
everything.
They
do
to
make
sure
that
there
weren't
as
many
problems
and
I,
know
that
at
least
if
it
compiles
a
certain
degree
of
checking,
has
been
done.
A
Obviously,
I
still
have
to
review
their
pull
requests,
but
it
like
helps
give
me
more
confidence
and
furthermore,
I
can
say,
go
take
a
weekend
and
play
with
these
projects
and
they
can
learn
more
about
systems,
programming
and
so
I.
See
rust
in
this
way
is
attracting
a
lot
of
people
who
have
traditionally
not
done
systems
specifically
because
this
C
Netta,
the
compiler,
makes
them
feel
much
more
safe
and
nice.
That
things
will
work,
and
so
this
is
something
this
very,
very
common
and
so
yeah.
A
So
tilde
and
slash
SCADA
has
been
very
happy
production
user
for
a
very
long
time.
It's
worked
out
extremely
well
for
them.
The
way
that
you
hooda
puts
it
is
we
are
a
10-person
team
competing
with
a
publicly
traded
company
and
we
still
ship
features
faster
and
have
customers
and
a
viable
business
anyway,
and
a
lot
of
that
is
due
to
how
rock-solid
they
use
rust
and
Java
and
Ruby
and
ember,
basically
as
their
stack
and
they're
like
all
the
technologies
you
chose
and
have
paid
out
really
well
and
then.
A
Finally,
the
last
production
user
I'd
like
to
talk
about
is
Firefox,
so
I
work
for
Mozilla.
As
I
said
earlier.
I
don't
do
any
work
on
Firefox,
which
is
cool,
I,
do
a
lot
of
traveling,
and
so,
when
I
tell
people
I
work
at
Mozilla,
the
Firefox
company
they're,
like
oh,
that's,
cool
but
I
use
Chrome
and
I'm
like
it's
cool
I,
don't
work
on
Firefox
I,
don't
care
the
song.
My
thing
I
use
iceweasel
because
I'm
on
Debian,
which
is
hilarious,
is
like
a
Mozilla
employee
I,
don't
actually
use
the
real
build.
A
If
you
know
any
of
that
history,
it's
terrible
and
we're
fixing
it
hopefully
soon,
but
trademark
copyright
free
it's
hard
anyway.
The
point
is,
is
so
Firefox
the
reason
that
Mozilla
has
invested
so
much
in
rust
and
we
think
of
rust
is
truly
being
a
community
project.
Mozilla
pays
most
of
the
people
that
work
on
rust,
full-time
but
like
we
have
about
40
people
that
are
involved
in
rust,
governance
and
about
half
of
them
are
Mozilla
employees.
A
When
we
did,
the
audit
last
were
basically
memory.
Safety
bugs
so
Mozilla
is
interested
in
rust
as
a
way
to
twofold,
so
we
want
to
improve
Firefox
but
other
time.
There's
this
thing
called
servo.
This
is
the
logo
they're
using.
Currently
they
don't
have
a
real
logo
yet,
but
they
also
have
a
good
sense
of
humor,
so
they
got
the
Doge
as
their
as
their
logo,
but
servo.
At
the
same
time
that
we
wrote
rust,
we
are
also
working
on
a
browser
rendering
engine
in
rust
and
there's
multiple
reasons
for
that.
A
One
of
them
is
that
if
you're
writing
a
new
programming
language,
a
common
tool,
you
want
to
make
sure
that
your
programming
language
is
good.
So
you
try
to
write
programs,
alongside
of
the
programming
language,
to
make
sure
that
your
language
is
good
at
writing,
actual
programs
and,
of
course,
because
you,
like
your
new
language
and
you're
working
on
this
compiler
all
the
time.
One
of
the
things
that
you
do
is
you
rewrite
your
own
compiler
in
your
own
language?
Because
that's
you
know
that
way.
A
We
have
a
whole
separate
team
of
people
that
are
working
on
just
building
a
web,
rendering
engine
and
by
rendering
engine
I
mean
like
WebKit
or
gecko,
not
like
Firefox
in
whole,
but
like
the
thing
that
determines
what
gets
drawn
on
the
page
where
and
so
we've
been
rewriting
one
of
those
completely
from
the
ground
up
in
rust,
although
it
does
use
a
number
of
seeded
C++
components
that
it
wraps
but
like
the
core
of
it,
is
all
in
rust
and
is
slowly
replacing
those
things
as
time
goes
on.
But
that
is
sort
of
twofold.
A
The
first
one
is
to
prove
out
rust
as
a
language
and
make
sure
that
it
works,
but
the
second
I
put
the
slide
out
of
order.
The
second
one
is
that,
like
servo,
is
slowly
moving
its
way
into
Firefox
as
well.
So
I
guess
I'll
talk
about
that
in
a
second,
because
I'm
gonna
show
you
these
things.
So
one
of
the
cool
things
about
servo
is
that
it's
massively
parallel
at
all
levels.
A
So
this
is
an
example
of
a
couple
months
ago
of
servo,
rendering
the
rust
subreddit
and
these
the
colors
on
the
boxes
indicate
a
different
thread
that
determined
where
that
layout
object
needed
to
go.
So
there
actually
are
like
we
are
using
multiple
threads
on
like
every
single
level,
and
it
demonstrates
the
kind
of
like
parallelism
that
has,
but
recently
there
was
this
talk
given
about
web.
Render.
That's
really
really
cool
web
render.
Is
this
new
technology
that
servo
is
pioneered
that
lets?
A
A
But
the
point
is:
is
that
with
web
render
there
they
haven't
found
any
real
web
pages
that
don't
render
at
hundreds
of
frames
per
second,
and
it's
not
so
much
that
you
want
web
pages
to
render
at
hundreds
of
frames
per
second,
like
even
gaming
monitors.
Don't
actually
give
you
that
kind
of
resolution.
But
the
point
is:
is
that
the
rendering
of
the
page
will
not
be
what
makes
it
slow
so
like
if
we
make
the
web
faster?
A
That
means
we
can
do
more
with
the
web
and
the
web
is
free
and
open
and
I
love
the
web
and
want
to
use
it
for
as
much
as
possible,
and
so
you
know
reducing
the
amount
of
overhead
that
it
takes
to
like
draw.
The
web
page
is
useful
for
enabling
new
things
happen
with
web
technology.
So
they
have
several
demos
that
using
this
talk
that
I
don't
have
time
to
show
you,
but
basically
boil
down
to.
A
If
you
create
a
specially
crafted
web
page
with
600,000
divs
on
it
and
then
use
css3
transformations
to
animate
them
into
like
a
swirling
vortex
that
will
run
in
60
frames.
A
second
and
web
render,
but
it'll
run
at
like
a
quarter
of
a
frame
per
second
on
Firefox
or
like
half
a
frame
per
second
in
Chrome
right
now.
So
there's
some
really
really
interesting
stuff
going
on
with
the
performance
aspect
here
and
as
I'm
as
I
mentioned
a
minute
ago,
we're
basically
moving
components
from
servo
into
Firefox.
A
So
if
you
download
Firefox
well
I'm
skipping
ahead,
that's
my
next
slide.
If
you
download
Firefox
today
from
Firefox
com,
if
you're
on
OS,
10
or
Linux,
there
is
some
rust
code
in
there
already,
a
very,
very,
very,
very,
very
any
amount
of
rust
code.
But
it's
there.
Yes,
that's
actually
the
hardest
part.
Like
imagine
imagine
what
the
Firefox
build
system
looks
like
now.
Imagine
introducing
a
new
programming
language
into
that
build
system.
It
it
took
a
while
Windows
is
gonna
happen
in
a
couple
releases.
There
are
some
things
whatever.
A
This
is
not
a
talk
about
the
internals
of
Firefox,
but
the
point
is:
is
that
we're
sort
of
taking
this
two-pronged
approach?
One
is
where
we
take
components
out
of
servo
and
put
them
into
Firefox
directly,
so
one
of
the
patches
that
is
not
landed
yet,
but
we're
hoping
to
land
relatively
soon
is
to
replace
the
URL
bar
and
all
of
its
parsing
and
stuff
that
it
does
with
rust
code.
A
Another
one
is
the
styling
and
layout
system,
and
so
those
components
are
like
working
their
way
into
Firefox
and
also
new
components
that
are
relatively
isolated,
are
trying
to
use
rust
first
as
a
way
of
getting
more
rest
code
into
Firefox,
but
the
ideas
that
sort
of
rust
will
slowly
eat.
Firefox
from
the
inside
outside
I
realized
this
mother's
done.
The
metaphor
I
didn't
know
which
way
it
actually
went,
but
whatever
the
percentage
of
rust
code
will
increase
for
various
reasons
and
then
also
in
June.
A
We're
gonna
release
a
demo
of
servo
as
a
browser
of
itself.
We're
basically
only
guaranteeing
that
three
or
four
websites
will
work
well,
but
the
idea
is
to
collect
telemetry
on
what
parts
of
the
web
platform
website
to
use.
So
we
know
which
parts
to
implement
next
and
the
cool
thing
about
that
is
it's
going
to
ship
with
this
project
called
browser,
dot
HTML.
So,
basically,
even
the
chrome
of
the
browser
is
actually
a
webpage.
A
A
But
if
that
were
to
be
a
thing,
you
could
customize
your
browser
using
only
HTML,
CSS
and
JavaScript
no
need
for
additional
complicated
stuff,
and
so
that's
really
really
neat
and
I
think
that
will
enable
a
lot
of
people
to
do
really
cool
stuff.
Ok,
so
that
is
all
the
time
that
I
have
to
share
with
you.
Unfortunately,
we
did
not
get
to
go
to
lunch
early,
because
I
actually
talked
a
lot
I
apologize.