►
Description
Firefox is in the process of shipping a new implementation of CSS styling written in Rust as part of Mozilla’s Servo project. Firefox has 20+ million lines of code and hundreds of millions of users, so this is no small undertaking! As a case study for integrating a large, multi-repo Rust project into a larger C++ project, this talk explains how we:
- created bi-directional FFI boundaries that maximized each project’s strengths
- addressed cross-language mismatches including threadsafety and ownership
- integrated two fast-moving codebases while managing regressions
We’ll cover specific successes and failures that emerged over the course of the project, and discuss how Rust contributed to those outcomes.
A
Good
morning,
so
Firefox
is
a
very
big
project.
There's
a
reason
why
people
keep
talking
about
Oh,
something
big
is
coming
into
Firefox.
Something
big
is
coming
into
rest
into
Firefox
and
that's
because
Firefox
is
a
really
big
C++
project.
It
is
over
nine
million
lines
just
of
C++
by
itself
and
then
there's
other
languages
of
languages.
On
top
of
that,
I
mean
the
engine
that's
written
mostly
in
C++.
A
We
tend
refer
to
as
gecko
and
gecko
has
a
style
system,
which
is
a
component
I'll,
explain
a
little
bit,
which
is
by
itself
about
160,000
lines
of
C++
code,
and
this
is
something
that's
been
around
for
almost
two
decades
now
and
has
like
evolved
over
time
and
grown
larger
and
larger
and
more
complex.
So
the
new
thing
stylo
is
85,000
lines
of
handwritten
rust,
and
that
is
an
important
qualifier
which
we'll
explore
later.
But
this
is
what
is
coming
to
Firefox
in
about
two
weeks:
it's
gonna
be
shipping
and
that's
really
exciting.
A
It's
been
a
number
of
years
of
effort
to
get
to
this
point.
So
let's
talk
about
what
a
style
system
actually
is
a
web
browser.
So
a
web
browser
basically
contains
a
pipeline
to
get
bytes
from
the
network
and
then
turn
them
into
something
that
shows
up
in
front
of
you
so
starts
with
the
HTML
parser,
and
this
takes
the
source
code
of
an
HTML
page,
which
contains
your
HTML
tags
and
everything
as
an
input
and
as
an
output.
A
It
turns
that
into
a
tree
of
what
are
called
Dom
nodes
and
these
two
these
correspond
to
those
tags.
Everything
inside
of
a
pair
of
matched
tags
becomes
an
element
and
everything
or
everything
inside
of
that
that
pair
of
match
tags
becomes
children,
child
nodes
of
that
element.
So
here
the
HTML
has
two
children
and
each
of
those
children
each
have
one
child
by
themselves.
A
So
the
next
step
we
go
through
is
the
Cascade,
and
this
is
from
the
name
of
CSS
that
stands
for
cascading
style
sheets.
That
means
that
for
every
element
in
the
tree,
we
will
proceed
through
the
tree
and
apply
these
style
rules
based
on
these
inputs
were
given
and
figure
out
what
the
actual
computed
styles
for
each
node
should
be.
What
color
in
this
case
is
each
element
going
to
be
based
on
these
rules?
So
we
look
and
say:
oh,
we
have.
A
We
see
that
we
have
a
div
with
an
ID
header,
so
we
can
apply
the
style
rule
to
turn
that
green
and
that
gets
inherited
by
all
of
its
children,
but
that
gets
overwritten
by
the
span
which
says:
oh
I
should
be
red.
So
we
take
the
result
of
these
computed
styles
and
then
we
feed
them
into
the
layout
component
and
that's
what
takes
both
your
your
tree
of
nodes
and
and
they're
their
actual
style
information,
we've
computed
and
then
says:
okay,
based
on
these
computer
styles.
Where
should
we
actually
draw
boxes?
A
What
is
the
size
of
each
box
how's?
It
relate
to
which
children
and
parents
what
how
are
they
aligned
together?
That
layout
is
what
takes
all
that
information
and
turns
it
into
something
that
you
could
end
up
visually,
seeing
and
so
the
style
system.
When
you
talk
about
it,
encompasses
a
number
of
your
steps,
it
encompasses
parsing
the
CSX
parsing,
the
CSX
CSS.
A
It
also
incorporates
the
Cascade
and
turning
everything
into
a
series
of
computed
styles.
It
also
incorporates
introspection,
so
javascript
is
able
to
ask
your
web
page.
What
is
the
computed
style
of
a
particular
element,
and
it
can
also
look
into
what
are
the
contents
of
the
style
sheets
that
the
browser
knows
about?
Furthermore,
their
CSS
animations
and
the
style
system
is
responsible
for
processing
those
at
any
given
time
and
figuring
out
what
the
values
that
are
being
animated
should
be.
A
And
finally,
whenever
a
page
is
modified,
then
the
style
system
is
responsible
for
determining
what
is
the
most
way
of
recomputing
all
that
information,
because
it
turns
out
it's
not
actually
very
performant.
If
you
go
and
either
rate
over
the
entire
tree
of
all
nodes,
every
single
time,
you
make
a
change
to
just
one
of
them,
so
you
might
ask
if
we
have
this
thing,
which
has
been
working
for
decades
and
Firefox.
What
is
was
the
reason
we
would
want
to
go
to
all
this
effort
to
replace
it
and
really
the
answer
is
performance.
A
A
A
However,
as
much
as
it
sounds
like
you
should
be
a
straightforward,
a
straightforward
operation
to
perform.
It
turns
out
that
it
is
more
complicated
than
that
and
there's
been
two
attempts
to
do
this
in
Firefox
itself
in
C++
in
the
past
few
years.
So
one
was
a
group
of
grad
students
at
UC
Irvine
and
they
had
an
advisor
working
at
Intel
and
they
published
a
paper
on
their
efforts
to
measure
and
and
do
more
of
the
work
in
parallel
and
it
seemed
to
go
really
well,
except
that
the
resulting
code
was
difficult
to
maintain.
A
There
was
a
lot
of
duplication.
It
was
difficult
to
reason
about,
and
in
general
it
didn't
actually
look
like
the
most
thing
to
spend
time
on,
given
how
many
other
parts
of
Firefox
we
could
be
focusing
on.
Similarly,
in
2011
we
decided
to
give
it
to
an
intern
which
surprised
me
but
came
up
with
a
patch
and
it
seemed
to
be
working,
but
there
were
these
mysterious
crashes.
They
were
really
difficult
to
track
down.
It
was
hard
to
debug.
A
So,
let's
talk
about
servo
servo
is
the
web
browser
engine
we've
been
building
since
2012
completely
from
the
ground
up
in
rest,
with
a
couple
minor
exceptions,
but
in
general
we're
we're
learning
we're
taking
lessons.
We've
learned
from
building
browsers
over
the
past
decade,
no
matter
Firefox
or
Chrome
or
WebKit,
or
something
we're
looking
at
the
best
choices
made
in
those
browsers
and
trying
to
build
something
new
in
rust.
A
A
All
the
Firefox
code
exists
in
a
mercurial
repo
and
the
servo
code
exists
in
a
github
repository
and
has
a
bunch
of
different
crates,
and
some
of
them
are
important,
as
some
of
them
are
not,
and
servo
also
chooses
to
make
use
of
the
crates
at
I/o
ecosystem.
It's
been
really
great,
but
what
it
means
is
that
for
Firefox,
this
is
a
problem
because
Firefox
uses
continuous
integration
servers
which
don't
have
any
external
network
access,
and
that
goes
against
the
model
that
is
traditionally
followed
by
cargo
projects.
So
what
happens?
A
Is
Firefox
actually
vendor
the
entire
source
code
of
servo
into
the
Firefox
repository
and
then
also
vendor
all
of
the
dependencies
of
servo
into
the
Firefox
repository,
which
is
an
interesting
stress
test
for
all
sorts
of
different
systems?
It
turns
out
and
honestly,
I,
wouldn't
actually
recommend
following
this
path.
It
I'm
glad
we
did
for
servo,
but
it's
actually
quite
a
pain.
A
So
let's
talk
about
how
this
actually
fits
together.
There's
a
crate
in
the
servo
source
code
called
gecko
lib,
and
that
contains
all
of
the
API
is
that
the
gecko
C++
code
can
invoke
in
order
to
call
in
to
the
servo
style
system.
There's
a
header
file
called
servo
binding
list
H
in
the
C++
gecko
code,
which
has
equivalent
C
declarations
for
all
of
those
functions,
because
the
way
you
can
do
cross
language
interaction
like
this
is
by
pretending
that
you
have
a
C
function
in
rest
code
and
then
the
C
code
goes.
A
Oh
I
know
how
to
invoke
C
code.
That's
great
I'll,
just
be
able
to
color
ate
into
that.
So
all
of
the
API
is
that
can
be
invoked
from
gecko
code
start
with
the
prefix
servo
underscore,
and
the
only
interesting
bit
here
is
that
we
don't
have
any
automatic
synchronization
here.
So
if
you
make
a
change
to
the
servo
API
is
that
are
provided
in
the
rest
code
and
you
change
like
you
had
an
argument
to
something.
That
means
you
also
need
to
update
this
header
file.
A
A
A
A
Declarations
are
generated
by
bind
JNT,
which
looks
at
a
C
header
file
and
spits
out
all
the
rest
declarations
you
need
in
order
to
use
those
types
and
in
call
those
functions,
it's
very
handy,
so
the
C
API
for
creating
an
error
reporter,
because
in
Firefox
a
CSS
error
that
gets
the
or,
if
there's
an
error
in
your
CSS
code,
that
gets
processed.
Then
we
want
to
notify
the
developer
tools
in
the
browser
about
that.
So
servo
doesn't
know
anything
about
Firefox
developer
tools.
A
A
So,
as
I
said,
we
use
by
and
Jen
to
avoid
any
mistakes.
It
just
generates
everything
automatically
and
if
you
ever
update
the
C,
API
or
the
that
gecko
provides,
then
those
automatically
get
reflected
into
the
rest
bindings
at
Build
time,
which
means
that
if
you
add
a
parameter
to
the
C
ones,
then
you'll
get
a
compile
error
in
any
uses
of
that
API
in
the
rest
code,
because
it
says
oh
there's,
you
know
you're
not
passing
a
parameter,
it's
necessary
and
that's
very
convenient.
A
You
don't
get
any
crashes
or
unexpected
behavior
that
way,
it's
also
extremely
slow
because
we
end
up
processing
dozens
or
hundreds
of
header
files
and
it's
extremely
easy
to
make
a
change
to
a
header
file
which
doesn't
actually
matter
to
rest,
but
is
transitively
included
by
something
and
then
that
you
have
to
run
this
whole
Banton
process
again.
So
that's
a
bit
of
a
frustration
for
us,
so
there's
sort
of
two
main
ways
that
you
can
focus
on
doing
your
across
language
interaction.
A
You
can
either
encapsulate
these
operations
behind
functions
or
you
can
dive
directly
into
the
types
and
manipulate
them
like
manipulate
C
types
from
the
rest
code
or
rest
types
from
the
C
code.
Either
one
is
possible,
but
it
turns
out
that
there's
bit
of
a
trade-off
either
way
that
usually
revolves
around
performance
versus
safety.
A
So
it
turns
out
that
every
time
you
call
a
function
in
general,
if
you're
calling
like
a
rest
function
from
rest
code,
the
compiler
says:
oh
I
know
what
that
function
is
I
can
see
how
big
it
is.
It
would
probably
make
sense
just
to
inline
that
code
directly,
rather
than
going
through
the
process
of
performing
a
call,
pushing
things
onto
the
stack
jumping
returning
back
all
these
things.
That
usually
happen
and
that's
fine,
but
every
time
you
do
a
cross-language
function.
Call
the
compiler
doesn't
know
anything
about
that
and
can't
avoid
this.
A
That
means
that
if
you're
going
back
and
forth
between
languages
during
code,
that
is
performance
sensitive
than
the
can
be
a
problem,
I
mean
the
benefit
of
using
a
function.
Is
that
if
you
have
in
very
invariants
around
what
your
data
model
is
doing
around,
what
do
types
are
supposed
to
be
doing?
You
can
assert
those
you
can
have
safety
checks,
and
that
is
very
helpful,
so
there's
a
bit
of
trade-off
there.
A
So
as
an
example
of
this
there's
there's
one
piece
in
in
stylo
where
we
need
to
talk
to
gecko
to
say:
okay,
this
particular
thing:
we
need
to
make
sure
it
is
marked
as
being
an
image
element
and
there's
too
much
involved
there
for
us
to
really
do
that
from
the
rest
code.
So
it's
just
a
simple
function.
A
So,
on
the
other
hand,
if
you're
using
types,
then
you
have
the
option
to
just
dive
directly
into
the
memory
and
start
modifying
things
and
there's
no
performance
penalty.
For
this.
It's
just
it's
just
a
memory.
You
have
pointers
to
it.
You
can
reach
in
and
set
things
or
read
things,
and
it's
up
to
you
to
make
sure
that
you're
actually
following
the
model
and
not
breaking
the
system.
A
I
think
the
downside
here
is
that
if
you
do
have
rules
around
what's
allowed
and
what
isn't
suddenly,
the
logic
is
now
distributed
between
like
two
completely
separate
files
and
two
different
source
trees
and
that
that
might
not
be
a
good
trade-off,
but
for
performance
sensitive
code.
Maybe
that's
what
you
want
an
example
of
where
we
do
this
I,
particularly
like
that,
like
there's
this
comment
that
explains
what
properties
of
the
model
that
we're
relying
on
in
order
to
do
this
mucking
around
inside
a
C
type
from
the
rest
code.
A
In
this
case,
we
have
a
pointer
to
a
C
type
and
we're
getting
a
mutable
pointer
to
a
field
inside
an
array
that's
stored
inside
that
type
and
then
setting
a
particular
field
of
of
that
subfield
to
another
rust
value
that
the
C
code
will
eventually
understand
when
when
it
gets
back
there,
so
we
actually
did
something
interesting
with
dealing
with
these
with
these
types
between
languages,
so
by
and
Jen
will
typically
just
give
you
declarations
which
involve
raw
pointers
everywhere
and
that's
fine.
You
know.
A
Raw
pointers
are
thing
that
you're
used
to
using
in
C,
for
example,
and
it's
not
that
bad
to
go
back
to
using
them
in
rest,
but
we
did
something
where
we
started,
naming
or
creating
these
types
in
in
rust,
which
wrap
raw
pointers,
but
they
have
particular
extra
meaning
associated
with
them.
So,
for
example,
we
created
this
the
so
generic
type
called
owned,
which
represents
a
a
raw
pointer
that
was
originally
created
from
a
value
like
a
box
in
rust,
and
so
the
idea
here
is.
A
Therefore
we
can
turn
it
back
into
a
box
and
it'll
be
de-allocated
safely
and
properly,
and
we
have
this
idea
of
ownership
that
persists
across
the
language
barrier,
even
though
c++
does
not
have
the
same
kind
of
ownership
model
as
rust-eze,
so
by
I'm
jen
does
this
for
us
automatically.
We
have
a
list
of
types
that
we'll
just
see
the
c++
type,
for
example,
ross,
perot
style
set
owned,
you'll,
say:
okay.
I
know
that
I
need
to
turn
this
into
this
actual
more
complex,
rust
type,
which
is
the
same
under
the
hood.
A
So
in
c++
it's
just
a
raw
planer.
If
but
it
has
the
same
name
and
we
have
a
function
which
is
declared
from
rest,
which
says:
oh
I
accept
this
raw
servo
style
set
owned
wares
on
the
rest
side.
We
say:
okay,
it's
not
just
a
raw
planer.
It
is
actually
this
type
called
owned
that
specializes
on
this
underlying
raw
pointer
and
in
the
actual
definition
of
servo
style,
set
drop.
A
We
accept
this
own
value
and
then
turn
it
into
a
box
which
will
be
de-allocated,
because
we
know
what's
going
on
here
and
we
do
the
same
for
other
interesting
types.
So
we
have
types
that
have
borrowed
attached
to
the
name
and
bind
and
we'll
turn
those
into
traditional
rust
references
for
us
and
similarly
borrowed
or
null
which
will
be
a
raw
pointer
which
might
be
null.
We
then
turn
into
an
option
value
around
a
rust
reference
which
gives
us
much
nicer
ergonomics
and
prevents
us
accidentally
dereferencing
null
pointers.
A
So
let's
talk
about
this
parallel
style
system
stuff,
we
built
it
back
in
2013,
it
was
handwritten
and
it
worked
fine,
but
we
switch
to
rayon
in
2016
and
that's
worked
out
really
well
for
us.
Rayon
is
the
library
that's
written
and
shared
by
lots
of
different
projects
that
do
things
in
parallel.
It
provides
a
safe
abstraction
over
sort
of
unsafe
operations
of
distributing
work
around
multiple
workers,
and
so
not
only
did
we
make
some
changes
to
rayon
to
better
accommodate
our
use
cases.
A
We
also
have
made
use
of
changes
that
other
people
from
other
projects
have
added
to
rayon
and
that's
been
a
really
nice
sort
of
synergistic
relationship
there.
So
the
idea
insert
in
stylo
is
that
we
have
a
queue
of
unstyled
nodes
and
it
will
literally
be
a
single
node
and
they'll
be
the
root
of
a
tree.
So
there's
a
pool
of
worker
threads
that
are
waiting
for
work
and
as
soon
as
work
becomes
available,
they'll
start
trying
to
grab
it
off
of
the
queue.
A
A
So
the
the
problem
of
trying
to
deal
with
here
is
that
parallel
code
in
general
has
some
problems
and
that's
that
code
executes
simultaneously
and
and
sharing
data
is
a
problem.
So
if,
if
they
only
read
the
same
data,
that's
fine,
everyone
can
read
the
same
thing.
You
get
a
consistent
view
of
the
world,
but
if
you're
reading
and
writing,
then
you
end
up
with
a
problem,
because
you
can
get
any
consistency
showing
up
or
if
different
things
are
writing
at
the
same
time,
still
more
inconsistent.
That's
no
good!
A
The
rest
compiler
protects
us
against
these
problems,
but
there
is
an
issue,
and
that
is
when
we
go
into
C++
from
a
worker
thread.
That's
running
on
a
thread:
we
lose
the
ability
of
the
rest
compiler
to
protect
us,
and
that
means
that
a
C++
method
like
get
brute
element,
as
shown
here
it
turns
out,
is
a
problem
because
it
actually
has
a
little
internal
cache.
The
first
time
is
called
it'll.
A
Look
for
a
root
element,
it'll
say:
oh
great,
okay,
we
can
do
this
faster
next
time,
if
I
just
store
this
as
a
member
in
this
class.
But
what
happens
if
you
have
two
different
workers,
which
both
call
it
at
the
same
time
for
the
first
time,
and
they
both
try
to
write
to
the
same
thing
together
or
read
it
at
the
same
time
turns
out
this
causes
a
crash,
and
it's
really
difficult
to
actually
spot
problems
like
this
for
a
while.
A
Our
lead
developer
was
trying
to
keep
track
of
like
reading
through
the
code,
thinking
really
hard
about
what
would
be
called
at
any
given
time
and
thinking.
Okay,
is
this
safe?
This
is
probably
safe.
This
might
be
safe.
Maybe
this
isn't
safe
and
that
doesn't
really
scale
it
turns
out.
So
so
it
turns
out.
We
came
up
with
some
simple
rules
to
avoid
this.
If
we
said
that
the
the
code
being
called
from
these
worker
threads
was
only
allowed
to
write
to
local
variables,
those
would
not
be
observed
by
any
other
workers.
A
They
can
read
from
anything
because
no
one's
writing
to
anything
and
the
main
thread,
which
is
usually
the
one
doing
all
the
writing
doesn't
get
to
run.
If
we
follow
those
rules,
could
we
get
the
compiler
to
help
us
do
this,
and
the
answer
is
yes,
we
have
a
compiler
plugin
for
GCC,
which
performs
static
analysis
on
all
functions
that
start
with
the
Gecko
prefix.
So
all
of
those
API
is
that
can
be
called
from
rest.
A
It
will
go
and
explore
every
single
possible
code
path
that
could
ever
execute
in
any
universe,
and
it
will
see.
Ok
are
any
writes
occurring
in
any
of
these
code
paths
to
anything
that
is
not
a
local
variable.
If
so,
that
is
an
error,
and
that
means
we
now
have
the
compiler
helping
us
and
telling
us
whether
anything
could
end
up
causing
a
crash
by
being
culled
from
these.
A
These
rust
workers-
and
this
is
kind
of
scary,
because
we
found
over
three
preexisting
problems
from
code
that
was
like
a
decade
old
that
was
only
now
causing
us
problems
because
we
were
doing
this
on
threads
and
it
saved
us
so
many
times
as
we
kept
trying
to
introduce
new
problems.
We
were
like.
Oh,
this
is
great
I'll,
let's
Cal
this
function
and
it's
like
nope,
you
can't.
A
So
let's
talk
a
little
bit
about
some
pain
points
that
came
from
this
this.
This
work
first
ones
memory
usage,
Firefox,
is
really
sensitive
about
memory
usage,
there's
a
sort
of
a
long-standing
meme
that,
like
there's
a
leak
in
Firefox
it'll,
just
keep
growing
over
time.
So
we
fix
that
a
few
years
ago.
So
that's
not
a
big
deal,
but
we're
really
careful
not
to
like
keep
having
memory.
A
Users
increase
and
we
have
infrastructure
which
is
good
at
measuring
current
heap
usage
throughout
the
program,
but
it
needs
pointers
to
the
actual
allocated
buffer
in
order
to
be
able
to
report
those
and
that's
finding
in
the
gecko
code,
because
we
wrote
our
own
standard
library.
So
we
have
all
those
pointers
everywhere.
We
can
dig
into
everything.
Rest
doesn't
actually
give
us
that
in
all
cases,
though,
and
turns
out
that
hashmaps
both
are
extremely
important
to
the
style
system
and
are
pervasive
everywhere,
and
they
also
get
really
big
sometimes.
A
So,
let's
imagine
a
CSS
property
called
borderless
style
which
could
have
three
different
values:
it's
either
none
or
solid
or
a
dashed
border.
We
might
represent
that
as
an
enum
with
three
states.
You
know
none
solid
or
dashed,
and
it
has
you
know
a
pixel
value
for
like
how
big
the
spacers
should
be
so
under
the
hood.
This
is
going
to
be
eight
bytes.
A
You've
got
four
bytes
for
the
actual
u-32
value
that
is
stored
in
the
enum,
and
you
also
have
four
by
for
the
tag
which
indicates
what
kind
of
what
kind
of
what
state
this
value
is
in
at
any
given
time
and
that's
unavoidable.
So
we
might
look
at
that
and
go
okay.
Well,
the
none
state
that
seems
redundant.
Why
don't
we
just
put
this
inside
of
an
option?
Options
are
much
nicer
to
use
to
get
better
ergonomics.
A
So
if
we
just
have
an
option
around
this
enum,
we
only
need
two
states
inside
of
it,
and
now
it
turns
out
that
border
style
value
is
still
the
same
size.
It
still
has
a
four
byte
tag
and
it
still
needs
to
store
four
bytes
for
the
u-32
value,
but
the
option
value
is
also
has
its
own
tag
and
that's
four
bytes,
and
then
you
need
to
store
the
eight
bytes
for
the
nested
enum.
So
in
total
your
option
value
is
now
12
bytes,
even
though
it's
still
still
representing
the
same
amount
of
data.
A
Now
we
will
look
at
this
and
say
what,
if
the
dash
width
was
optional,
what
if
you
didn't?
Actually
like
what,
if
there
was
like
a
default
that
would
be
specified
automatically,
you
might
say:
okay!
Well,
let's
make
the
option
inside
the
dashed
thing.
So
now
we
have
an
option
of
an
enum
that
contains
an
option
sometimes,
so
this
adds
up
the
option.
U32
is
itself
8,
bytes
4
bytes,
for
the
tag
4
bytes
for
the
value.
A
Then
you've
got
the
border
style
value
which
has
4
bytes
for
the
tag,
and
now
it
stores
an
8
byte
enum
and
the
overall
enum
is
still
4
by
tag
now.
It
stores
8
bytes
for
the
value,
so
you've
got
16
bytes
for
storing
the
you
know,
almost
the
exact
same
amount
of
information
now
so
our
option
here
is
that
we
could
flatten
this
automatic
or
not
automatically.
But
we
can
flatten
this
manually
and
put
this
all
back
into
a
single
enum
that
contains
all
the
different
states.
A
A
Another
thing
we
came
across
is
that
the
the
arc
values
contained
we
pointers,
and
this
is
something
a
silo
doesn't
actually
use,
and
this
means
that
there's
an
extra
four
or
eight
bytes
per
thing
you
allocate
inside
of
an
arc
wrapper,
and
we
do
that
a
lot
in
servo,
so
there
there
seem
to
be
some
discussion
going
on
about
whether
this
is
necessary.
We
decided
that
we
should
just
fork
arc
to
get
rid
of
it,
compiling
time
kind
of
not
wonderful
all
the
time.
A
There's
you
know
three
hundred
thousand
lines
of
rust
code
after
you
go
through
all
the
cogeneration,
just
for
the
largest
crate,
and
that
isn't
easy
to
do.
Quick
work
on
you
know
minute.
34
debug
build,
but
performance
is
terrible.
Meanwhile,
six
and
a
half
minutes
for
release
build
if
you
get
good
performance
and
we
only
use
stable
rest,
so
we
can't
try
a
lot
of
the
new
things
which
are
coming
out
recently
and
finally,
fallible
allocation
is
really
important
for
Firefox
because
we
need
to
be
able
to
not
break
the
browser.
A
If
you
know
you
run
out
of
memory
or
some
web
content
says,
you
know,
gives
you
content.
That
is
really
really
large.
That's
no
good-
and
this
is
in
particularly
important
on
Windows
for
us,
because
it
has
very
different
behavior
than
other
river
platforms.
So
you
know
this
isn't
great,
there's
an
IRC
being
discussed,
but
it's
not
ready
yet
and
we
needed
to
be
able
to
ship,
and
we
were
seeing
crash
reports
of
failed
allocations
coming
up
heavily
on
windows.
Standard
library
doesn't
allow
it
so
we
forked
hashmap
it's
disappointing.
A
A
The
fact
that
people
are
really
happy
to
write
asserts
in
their
code
means
that
we've
caught
bugs
that
have
been
lurking
in
Firefox
around
the
old-style
system
that
were
just
swept
under
the
rug,
but
they
now
panic
in
the
new
style
system
and
we've
caught
bugs
are
a
decade
old.
Because
of
this,
that's
pretty
cool
and
crazy.
Io
has
been
very
helpful.
There's
lots
of
really
great
packages.
A
We
depend
upon
so
I
want
to
leave
you
with
this
final
conversation,
I
oversaw
I
overheard
in
in
an
see
channel
from
some
of
the
long-term
Firefox
developers
who
have
been
saying
that
they
they
have
found
using
rest
for
stylo
to
be
an
incredibly
positive
experience.
The
lead
developer
someone's
been
working
on
Firefox
for
like
seven
or
eight
years.