►
From YouTube: Rusty Days 2020 - Jan-Erik Rediger: Leveraging Rust to build cross-platform mobile libraries
Description
Agenda ► https://rusty-days.org/agenda
Slides ►https://rusty-days.org/assets/slides/06-cross-platform-mobile-libraries.pdf
Playlist with all talks ► https://www.youtube.com/playlist?list=PLf3u8NhoEikhTC5radGrmmqdkOK-xMDoZ
Follow ►
Facebook: https://rusty-days.org/facebook
Twitch: https://rusty-days.org/twitch
Twitter: https://rusty-days.org/twitter
This video ►
At Mozilla, Firefox is not the only product we ship. Many others — including a variety of smartphone applications, and certainly not just web browsers — are built by various teams across the organization. These applications are composed of a multitude of libraries which, when possible, are reused across platforms.
In the past year we used Rust to rebuild one of these libraries: the library powering the telemetry in our mobile applications is now integrated into Android and iOS applications and will soon be powering our Desktop platforms as well.
This talk will showcase how this small team managed to create a cross-platform Rust library, and ship it to a bunch of platforms all at once.
A
All
right
welcome
everybody
welcome
to
rusty
days.
Let's
get
started,
I'm
jan
eric,
I'm
your
speaker
today.
I
am
a
firefox
11g
engineer
on
firefox
working
at
mozilla,
I'm
also
a
russ
community
team
member,
and
sometimes
I
even
go
scuba
diving
you'll
find
me
online
and
you
even
find
the
slides
online
already
I'll
link
them
later
on
twitter
and
the
chat
as
well.
A
When
I'm
not
doing
any
of
the
mentioned
things,
I
also
organize
russ
conferences.
I
do
organize
the
european
conference
rust,
fest
and
just
as
rusty
days,
it
should
have
had
happened
as
an
in-person
conference
this
year.
It
should
have
been
in
the
netherlands,
but
unfortunately
that
didn't
happen.
It's
still
happening
this
year,
though
it's
gonna
be
online
and
it's
gonna
be
in
november,
so
stay
tuned
for
more
information
on
that
as
well.
A
A
A
A
A
Most
of
our
developers
on
firefox
actually
run
some
high-end
laptop,
a
macbook
or
binkbed,
or
something
else
so
on
their
laptop,
obviously
most
of
the
time
and
actually
runs
fast,
but
they
can't
test
on
all
the
hardware.
That's
out
there,
so
we
they
want
to
see
the
data
that's
coming
in
from
actual
users
and
how
it
behaves.
A
So
by
collecting
the
time
the
the
garbage
collector
takes
to
run
on
any
arbitrary
website,
a
user
might
visit,
they
can
make
decisions
whether
they
are
satisfied
with
the
performance
or
not.
There
might
be
outliers
in
either
direction,
but,
as
you
can
see
in
this
graph,
it
it's
more
or
less
a
normal
distribution,
and
I
guess
for
them.
This
is
what
they're
aiming
for
now.
This
is
just
a
single
metric,
but
this
is
already
useful
to
describe
what
we're
doing,
because
this
is
only
about
a
technical
data
point
inside
the
browser.
A
A
A
A
A
And
last
but
not
least,
we
want
to
engage
our
users,
just
as
the
firefox
code
base
itself,
the
data
collection
code
and
data
about
the
how
we
do
all
of
this
is
freely
available.
Users
can
look
at
what
the
browser
does,
and
on
top
of
that,
users
can
also
look
at
what
their
browser
specifically
is.
Collecting.
A
We
always
follow
these
principles
and
we
actually
have
people
that
ensure
that
every
data
we
collect
follows
these
principles
if
you're
interesting
interested
more
in
the
behavior
behind
all
of
that
and
the
ideas
behind.
All
of
that,
you
should
check
a
talk
by
my
colleague,
chattan
titled,
collecting
there
responsibly
and
at
scale
it's
from
last
year's
star
con
2019,
and
it
really
is
a
really
good
resource
to
describe
how
we
do
this.
A
A
A
The
outcome
of
out
of
all
of
this
is
glean,
which
is
a
the
new
development
going
all
the
way
from
the
sdk.
That's
the
code,
that's
actually
landing
in
the
products
over
to
the
pipeline,
which
ingests
the
data
puts
it
in
the
database
and
maybe
transforms
it
to
some
extent
and
then
also
the
tooling
to
analyze
and
look
at
this
data.
A
A
They
wanted
to
build
this
new
version
of
the
browser
on
modern
principles
in
a
modular
approach.
Using
the
existing
firefox
code
base
using
the
existing
modern
firefox
code
base
to
be
precise,
they
also
knew
that
they
wanted
to
have
data
about
how
this
product,
or
this
browser,
behaves
on
actual
end
user
phones.
A
The
landscape
of
android
is
even
wider
than
the
hardware
landscape
for
mainstream
operating
systems
on
the
desktop.
So
it's
even
more
out
of
scope
to
test
it
on
all
those
platforms.
But
if
we
can
get
actual
performance
and
usage
data
of
the
browser
in
the
wild,
then
we
can
make
decisions
what
works
and
what
doesn't.
A
Now,
let's
take
a
look
into
what
the
current
telemetry
api,
as
used
in
firefox
desktop,
looks
like
this
is
a
simple
function
call
and
all
it
does.
Is
it
increments
a
counter
that's
identified
by
some
name
and
increments
that
essentially
by
one
now?
The
first
thing
you
see
is
the
function
the
scalar
add,
which
is
called
on
some
global
telemetry
object.
A
A
A
A
Instead,
we
stop
at
a
certain
version
to
collect
this
data
and
by
then
whoever
is
responsible
for
this
needs
to
make
a
decision
about
the
data
and
how
it
answers
the
question
and
last
but
not
least,
there's
also
some
form
of
owner
in
this
definition
file.
We
have
always
at
least
someone
assigned
that's
responsible
for
this
metric.
So
if
anything
goes
wrong
there
or
someone
needs
more
information
around
this
data
or
needs
to
find
some
analysis
that
happened.
A
A
First
of
all,
we're
passing
in
some
opaque
string,
that's
used
as
an
identifier,
but
suddenly
there
are
like
underscores
and
dots,
and
it's
not
really
clear.
What's
the
pattern
behind
that
in
the
definition
file
browser
engagement
was
actually
done
with
a
dot,
but
here
it's
underscore,
but
then
there's
a
dot
between
the
category
and
the
name,
and
all
of
this
is
very
opaque
to
the
use
to
the
developer.
That
needs
to
use
this
also,
if
they
mistype
this
name,
there's
no
indication
that
something
doesn't
work.
A
A
Now
the
browser
engagement,
that's
a
category
and
that's
an
actual
object
available
in
the
source
code
and
the
counter
metric
is
now
identified
by
an
actual
by
an
actual
field.
On
this
object,
and
as
we
know,
this
is
the
counter.
We
also
know
what
methods
counter
supports.
In
our
case,
that's
add,
because
we
only
can
increment
this
counter
and
incrementing
works
with
an
amount,
so
we
can
pass
it
a
positive
integer
and
because
we
have
this
definition
file,
we
have
all
of
this
information
about
the
metric
readily
available
before
compile
time.
A
So
we
can
do
stuff
with
it
to
expose
all
of
this
information
to
the
developer.
If
we
get
to
this
api,
what
works
automatically
is
tab,
completion
for
browser
engagement
and
for
max
current
tab
count.
What
also
works
is
tab,
completion
for
the
right
method
that
you
can
call
on
this
and
you
automatically
get
a
type
check
for
what
needs
to
be
passed
to
this
method.
A
A
We
also
know
that
we
current
we
first
aimed
for
android,
so
we
needed
to
have
this
available
in
kotlin,
but
the
other
thing
we
knew
is
that
if
we
built
the
system,
it
needs
to
work
on
multiple
platforms
at
some
point,
because
we
also
want
to
get
that
into
our
other
products
and
that
could
be
ios.
That's
our
desktop
browser
shipped
on
multiple
operating
systems
and
potentially
other
applications
as
well,
and
to
not
redo
all
the
work.
A
All
of
this
should
be
bundled
in
a
single
core
implementation
that
can
be
used
cross-platform
and
last
but
not
least,
we
want
an
ergonomic
api
and
I
said
before
we're
targeting
different
platforms,
which
also
means
we're
targeting
different
programming
languages
in
which
those
products
are
implemented,
and
we
want
essentially
the
same
nice
api,
but
with
the
right
feeling
per
the
language.
We're
implementing
it.
For
now,
glean
is
the
summary
implementation
of
all
of
this
glean
is
the
project
that
we
built
with
a
rust
core
library
that
extends
to
multiple
platforms,
which
we
now
all
support.
A
A
A
A
A
It
keeps
track
of
some
internal
metrics,
so
we
not
only
measure
the
application,
but
we
can
also
measure
glean
itself
and
provide
some
metrics
that
are
used
in
essentially
every
implementation
as
well.
Now.
The
advantage
of
this
is
this
is
really
just
a
rust
crate.
All
the
rust
tooling
works.
We
can
rust.
We
can
test
this
by
just
running
cargo
test
and
it
works.
It
works
on
every
normal
operating
system,
be
that
mac
os
windows
or
linux,
and
that
makes
development
of
this
part
really
really
comfortable
for
us.
A
A
This
is
essentially
a
very
simplified
version
of
the
counter
we
talked
about
before.
A
counter
has
an
add
function
with
an
amount,
and
all
it
needs
to
do
is
look
into
the
database
and
increment
whatever
is
in
there.
We
have
some
other
metrics
that
are
a
bit
more
complex,
but
all
most
of
the
logic
for
them
is
still
implemented
in
rust,
which
allows
us
to
test
them
individually.
A
A
Rust
from
the
beginning
of
becoming
a
thing,
was
able
to
interface
with
other
programming
programming
languages
through
this
foreign
function,
interface,
ffi
for
simplicity,
the
ffi
is
essentially
a
deterministic
and
simple
naming
of
symbols
such
as
functions
as
you
have
them,
and
it's
also
the
c
compatible
api.
That's
the
application,
binary
interface,
which
essentially
describes
how
things
are
laid
out
in
memory
and
how
functions
need
to
get
called
and
where
to
pass
parameters
into
those
functions.
A
Rust
is
able
to
cross
the
ffi
in
both
directions.
The
first
is
calling
c
functions.
That's
when
you
want
to
integrate
an
existing
external
c
library
and
use
that
to
do
your
work.
The
way
you
do
this
is
you
need
to
copy
and
convert
the
declarations
of
all
the
function.
Calls
that
you
know
from
this
library
into
its
trust
equivalent.
A
You
then
put
them
in
this
extern
block
and
then
also
need
to
swap
around
the
types
so
that
you're
not
using
the
c
types,
but
using
their
equivalence
and
rust,
and
then
you
can
just
call
this
as
if
it
is
a
normal
rust
function
during
the
build.
This
all
hopefully
gets
linked
together
properly
and
you
get
a
working
library
out
of
this.
A
A
A
Now
the
cabi
is
much
less
expressive
in
what
it
can
do
compared
to
what
rust
is
able
to
do
so.
You
will
always
have
the
case
that
you
need
to
convert
into
something
that
the
seaside
can
actually
understand,
and
you
can
always
see
on
this
little
example.
One
of
the
cases
where
that
is
the
where,
where
that
comes
out
and
that's
strings
in
sea
land
strings,
are
always
encoded
with
a
null
byte
at
the
end,
whereas
in
rust
land
strings
always
carry
their
length,
so
you
need
to
convert
back
and
forth
between
those.
A
A
Next
up
to
make
this
all
work,
you
actually
also
need
the
declaration
of
your
function
in
c.
So
c
knows
what
to
call
and
the
compiler
knows
how
to
do
this.
Usually
you
would
write
this
somewhere
in
a
code
or
provide
a
header
file,
but
there's
a
tool
that
does
this,
for
you
c
bind
shank
can
create
the
c
header
automatically.
A
A
One
more
thing
that
we
use
in
glean
is
the
crate
called
ffi
support.
Ffi
support
is
a
small
library
that
helps
us,
simplify
implementing
all
these
ffi
stuff,
it's
not
written
by
us,
but
by
another
team
at
mozilla,
the
application
services
team.
They
do
essentially
similar
things
as
we
do
writing
rust,
libraries
and
shipping
them
to
mobile
platforms.
A
They
came
up
with
ffi
support
and
we're
very
happy
users
and
contributors
to
this
great
as
well.
One
thing
ffi
support
gives
us
is
the
into
ffi
trade.
The
into
f
of
I
trade
is
a
mechanism
to
express
how
to
convert
rust
types
into
ffi
compatible
types,
an
other
few
little
things
in
the
code.
This
allows
us
to
basically
write
dress
code
and
then
have
the
conversion
to
c
compatible
type
done
automatically
whenever
we
pass
this
through
our
ffi
functions,
I
said
before
there's
c
string
that
does
this
for
strings
and
f.
A
Well,
another
thing:
if
I
support
brings
us,
is
ffi
string.
I
mentioned
strings
a
couple
of
times
now
has
now
terminated
a
list
of
bytes.
Whatever
vi
screen
gives
us
essentially
a
safe,
wrap
around
this.
So
when
we
get
a
string
passed
in,
we
actually
have
a
rust
type.
We
can
work
with.
We
can
turn
this
into
an
actual
rast
string
or
read
data
out
of
it.
A
A
The
c
side
on
could
just
remove
this
data
after
this
function
returns,
so
we
can't
rely
on
it.
The
third
thing
we
get
from
ffi
support
is
the
concurrent
handle
map.
This
is
essentially
a
locked
map
that
gives
us
handles
to
the
data
we
insert.
These
handles
can
be
expressed
as
simple
integers
and
simple
integers.
We
can
just
pass
back
over
the
ffi
when
we
get
back
such
an
handle.
A
If
you
would
use
pointers
to
any
of
the
data,
the
other
side
could
easily
screw
up
the
pointer
handling
or
pass
pointers
in
the
one
place,
and
we
would
never
know
until
we
actually
see
a
crash
by
using
a
concurrent
handle
map
here
we
get
another
benefit.
This
is
all
behind
a
lock.
So,
even
if
we
get
called
from
a
multi-threaded
application,
we
are
automatically
threat
safe,
simply
because
our
data
is
behind
a
lock
and
we
never
allow
two
indications
to
run
them
that
data.
A
A
Most
people
will
probably
write,
compile
and
run
the
ros
code
on
their
own
machine.
You
have
your
laptop,
you
type
your
ros
code,
you
type
cargo
run.
It
builds
and
runs
the
code,
but
sometimes
you
probably
also
want
to
compile
to
that
other
machine
over
there
and,
as
it
turns
out
you're
programming
on
windows,
but
that
machine
over
there
is
linux,
because
it's
your
server.
A
So
how
do
you
do
this?
That
part
is
called
cross
compiling
now.
Luckily,
the
rest
compiler
is
a
cross
compiler
by
default.
It
knows
how
to
compile
for
other
targets
if
you're
using
rest
app.
You
can
just
type
restart
target
list
and
you
get
a
list
of
all
the
targets
that
rust
actually
knows
now.
These
are
over
80
targets
that
rostop
can
already
deliver
to
you
now.
Why
are
some
installed?
And
why
not?
A
Well,
there's
still
like
some
pre-compiled
libraries
like
the
standard
library
provided
for
all
these
targets,
so
you
just
need
to
download
them
first
and
then
you
can
build
your
code
now.
What
is
the
target
you
made?
Might
ask?
Well,
it's
essentially
the
combination
of
the
architecture,
the
operating
system
and
the
api.
You
want
now
sometimes
there's
an
operating
system,
so
it's
just
unknown
and
most
of
the
time
the
api
actually
specifies
what
lipc
you're
compiling
against,
which
then
makes
certain
assumptions
about
the
abi.
A
The
target
is
is
expressed
as
a
triple
now.
The
triple
has
three
to
five
components,
as
you
see
here
and
depending
who
you
ask,
and
I'm
not
totally
ignoring
the
one
or
off
by
one
or
more
error
here
now.
This
is
the
list
of
the
10
targets,
the
glean
sdk
actually
compiles,
for
we
have
four
targets
for
android
alone,
for
both
rm
and
x86,
and
one
of
them
is
actually
the
x86
emulator
or
simulator.
A
A
A
It
defines
a
way
for
the
bytecode
that
android
compiles
from
managed
code
to
interact
with
native
code,
manage
code
here
means
kotlin
or
java
and
native
code
here
means
anything
that
exposes
the
c
api
that
could
be
c
for
assets
rust
now
jni
is
a
bit
special
there's
a
crate
out
there
called
jni,
which
provides
you
a
lot
of
the
things
around
this
to
make
this
all
work.
But
let's
look
at
hello
world
example
for
jni
on
the
left.
You
see
the
rust
code
that's
necessary
to
make
jane
eye
work
again.
A
Then
you
have
an
extern
system
declaration,
that's
essentially
extern
c,
with
a
little
bit
of
other
details
on
some
platforms,
and
then
you
have
the
function
name
and
the
function
name
here
is
java,
underscore
hello
world
underscore
hello
and
that's
already
kinda
awkward.
You
need
to
encode
actual
information
into
this
type,
so
the
jni
site
can
find
this
on
the
right
side.
You
see
the
java
code
that
is
able
to
call
the
native
code.
Here.
A
A
To
repeat,
we
wanted
to
connect
kotlin
with
the
underlying
ffi
library,
that's
written
in
rust
and
the
next
project
you're
stumbling
across.
If
you
look,
this
up
is
jna
jna
is
the
java
native
access
and
accord
again
here.
Jna
provides
java
programs
easy
access
to
native
shared
libraries
without
writing
anything
but
java
code,
no
jni
or
native
code
is
required
again
java.
Here
you
can
replace
with
kotlin
the
same
applies.
A
We
can't
talk
to
some
native
code,
that's
c
or
rust,
or
whatever
looks
like
c
and
can
call
this.
So
let's
look
how
the
hello
world
for
this
looks
like,
and
this
is
the
hello
world
code-
that's
essentially
the
same
code.
I've
shown
before
we
have
our
no
manual
attribute.
We
have
extern
c,
we
define
our
function
with
its
normal
name
and
then
we
pass
around
what's
essentially
c
types
on
the
kotlin
side.
We
need
to
load
this
library
and
it
looks
like
a
little
bit
more
code,
but
just
it's
not
really.
A
You
just
need
to
tell
it
the
name
of
the
library
that
you're
loading,
then
you
need
to
list
out
all
the
declarations
of
the
functions
that
are
available
on
this
library
and
later,
as
seen
in
the
last
line,
you
can
call
this
as
if
it
was
pure
kotlin
code
under
the
hood.
Jna
takes
care
of
passing
things
back
and
forth
over
the
ffi
now
to
fit
this
all
together.
There's
one
more
thing:
we
need.
A
We
need
to
integrate
this
into
the
build
system.
Android
applications
use
gradle
as
their
build
system.
Most
of
the
time
now.
Luckily,
for
me
and
my
team,
we
didn't
need
to
write
anything
to
make
this
all
happen.
Others
figured
this
out
before
us.
As
I
said,
the
application
service
team
was
a
bit
quicker
in
building
that
project,
so
they
built
the
rust
android
gradle
plugin.
A
That
essentially
gives
us
what
you
see
here
in
the
slide.
We
can
add
this
little
cargo
block
into
our
build
files.
We
give
it
the
name
of
what
we're
trying
to
build
and
where
to
find
the
code,
and
we
also
tell
it
the
targets
it
needs
to
compile.
For
now.
Whenever
we
run
a
full
gradle
build
of
our
library,
this
plugin
under
the
hood
invokes
cargo,
finds
the
right
tool
chains
and
compilers
and
linkers
for
the
android
platforms.
A
A
A
A
Python
again
is
pretty
similar
conceptually
to
the
swift
implementation,
we're
using
cffi,
a
python
library
that
can
also
load
the
c
header
and
at
runtime.
It
then
loads
the
dynamic
library
and
provides
us
access
to
the
methods
that
we
defined
in
the
c
header,
there's
a
little
bit
more
involved
to
convert
between
python
types
and
c
types
simply
because
python
has
very
different
layout
of
types
than
c
expects
them,
but
with
some
tooling
and
utilities,
that's
not
actually
too
much
work
except
needing
to
write.
All
of
this.
A
A
There's
a
slight
shift
in
how
we
need
to
design
this,
and
a
lot
of
the
parts
are
already
in
firefox
to
make
this
all
happen.
So
if
you're
using
firefox
nightly,
you
will
soon
actually
use
glean
as
the
telemetry
system
inside
firefox
as
one
of
the
telemetry
systems
and,
last
but
not
least,
we're
actually
working
on
a
rust
api.
Now
you
might
wonder:
wait
you're,
writing
rust.
Why
don't
you
have
a
rust
api?
A
The
reason
is
glean
core
is
written
in
a
way
that
the
clean
ffi
can
expose
all
its
functionality,
but
we
didn't
bother
yet
to
provide
a
nice
api
on
top
of
all
of
this
to
make
it
usable
for
us
users,
we
simply
didn't
had
anyone
that
needed
that,
but
now
we
have
the
first
request
to
actually
provide
a
rust
api,
not
only
in
firefox
desktop
but
also
outside.
So
we're
going
to
work
on
a
rust
api,
that's
usable
simply
as
a
roscrate.
A
A
A
A
A
A
A
A
A
So
if
you
pass
over
a
kotlin
string
into
the
ffi
under
the
hood,
jna
allocates
new
block
of
memory
for
that
string,
copies
over
the
string,
utf-8
encoded,
if
you
tell
it
so,
adds
the
nullbyte
and
then
passes
over
a
pointer
to
this
allocated
data
after
the
function
call.
It
will
actually
also
make
sure
this
data
is
deleted
again.
A
A
A
We
then
turn
that
into
a
c-string
using
which
adds
the
nullbyte,
and
then
we
return
a
pointer
to
the
stator
and
also
need
to
make
sure
we're
not
de-allocating
that
data
on
the
kotlin
side
we
get
this
pointer
and
then
need
to
get
the
data
out.
Some
utility
functions
again
make
this
really
easy
for
us.
A
First
of
all,
on
the
bottom,
you
see
get
resting.
This
just
reads
out
the
null
terminated
string
from
the
pointer
reads
it
as
udf-8
encoded
data
and
turns
that
into
a
kotlin
string
on
the
top
is
the
function
that
developers
would
actually
or
that
we
actually
use
in
the
kotlin
bindings
get
a
consumer
string.
A
The
little
detail
you
need
to
know
here
is
that
you
also
need
to
ensure
that
the
allocation
on
the
rest
side
is
freed
again.
So
when
we
copied
out
the
data,
we
tell
the
ffi
to
just
deallocate
the
just
allocated
string
again
now
again
we
have
this
double
allocation.
Where
rust
allocates,
then
kotlin
allocates
copies
of
our
data
and
then
tells
rust
to
deallocate
again.
A
A
A
Now,
there's
one
little
detail
that
makes
this
a
little
bit
of
a
hassle
and
that
we
need
to
ensure
that
both
the
kotlin
side
and
the
rust
side
agree
exactly
about
the
order
of
variants
in
the
enum
and
also
the
values
of
the
enum.
Luckily,
if
you
don't
tell
them
otherwise,
they
will
both
start
counting
at
zero.
A
We
need
to
do
this
translation
all
manually,
but
this
is
certainly
a
part
which
we
could
automate
eventually
now
rust
actually
has
another
enum
type.
Well,
it's
not
another
type,
but
it's
an
extension
of
enums
enums
can
carry
data
by
this
you're
allowed
to
have
different
variants,
carry
different
data
and
the
whole
thing
is
still
signal
type.
A
A
This
is
specified
in
rust
and
what
it
does
it
turns
this
enum
when
converted
into
a
c
type
into
essentially
a
tech
union
and
uses
a
tag,
that's
represented
as
a
ui
u8,
that's
one
byte,
the
stack
then
essentially
just
encodes,
which
variant
the
union
has.
That
is
one
of
the
three
variants.
In
this
example,
on
the
right
side,
you
see
what
this
tech
union
would
look
like
in
c.
This
is
what
c
binding
actually
generates
from
this
representation
of
the
enum
at
first
you
get
the
different
tags.
A
Then
you
see
that
the
tag
is
actually
encoded
as
the
un8,
which
is
the
eight
bit
integer
and
then
for
each
variant
that
has
data
we
have
their
own
struct.
In
this
case,
we
have
the
upload
body,
which
contains
the
document
id
and
the
body
that
you
also
see
in
the
ros
code,
but
at
the
very
first
field.
It
contains
this
tag
and
last
in
this
sample
of
code,
you
see
the
union
now
c.
Bunchen
is
actually
smart
enough
to
see
that
neither
rate
nor
done
have
additional
data.
A
So
all
the
information
you
need
to
carry
around
for
them
is
the
tech
they
don't
need.
Their
own
structure
upload,
on
the
other
hand,
does
need
the
structure
and
making
this
a
union
means
that
the
union
simply
has
the
size
of
the
biggest
of
its
variance,
which
in
this
case
is
the
struct,
but
because
the
tag
is
always
the
first
variable.
In
this
whole
thing,
you
can
always
weed
out
the
tag
and
get
valid
data
back
and
if
it
points
to
upload,
you
are
allowed
to
read
the
upload
body.
A
A
There's
one
little
knit
again.
This
is
mostly
a
manual
process
translating
the
rust
code
on
the
left
to
the
cutling
code
on
the
right,
and
that
is
a
little
bit
annoying.
And
if
you
get
this
wrong,
you
might
accidentally
read
uninitialized
memory
and
that's
not
good,
so
you
need
to
make
double
sure
that
both
sides
agree
on
how
the
data
looks
like
this
is
also
a
part
where
I'd
like
to
see
this
just
being
automated.
A
We
turn
our
we
serialize
our
data
into
json
turn
that
json
into
a
c
string
and
return
that
c
string
on
the
kotlin
side.
We
read
the
string,
read
it
out
as
a
kotlin
string,
then
parse
the
json
and
can
then
look
at
the
json
data
again.
This
works
for
us
because
we
only
use
this
for
test
functions,
so
we
are
first
fine
with
the
performance
it
provides
us
and
we
also
find
with
the
little
bit
of
overhead.
A
It
has
on
us
as
developers
where
we
need
to
ensure
the
json
representation
is
seen
the
same
on
both
sides,
both
in
rust
and
kotlin,
and
the
last
thing
is,
you
could
just
drop
all
this
and
actually
just
use
protobuf.
That's
what
the
application
service
team
is
using
for
much
richer
data.
They
need
to
return.
A
The
advantage
is
they
can
define
their
data
layout
once
and
then
have
the
protocol
protobuf
compiler
generate
both
rust
code
and
kotlin
code,
then
their
ffi
simply
serializes.
The
data
into
a
protobuf
returns
that
over
the
ffi
and
the
kotlin
site
deserializes
that
using
the
generated
code
and
has
an
actual
kotlin
object
to
work
with
this.
Not
only
gives
you
the
safer
translation,
where
you
don't
need
to
do
this
all
manually.
A
A
A
R8
essentially
takes
the
jvm
byte
code,
then
minifies
and
optimizes
this
code
for
a
lot
of
application.
This
is
very
essential.
The
optimizations
it
can
do
are
very
impressive
and
really
speed
up
certain
applications.
A
lot.
The
problem
is,
it's
pretty
buggy
in
some
places
and
it
actually
might
over
optimize
j
and
a
code.
A
A
Additionally,
you
probably
want
to
tell
it
to
not
touch
your
own
ffi
code,
either.
That's
what
the
last
rule
does
for
us.
There
still
might
be
bugs
and
we
stumbled
up
on
a
big
one.
We
found
a
workaround
for
that
and
we're
hoping
this
bug
actually
gets
fixed,
but
this
is
def
sorry.
This
is
definitely
a
part
that
cost
me
a
lot
of
time
invested
into
trying
to
fix
this
now.
A
One
more
thing
I'd
like
to
talk
about
is
extra
libraries
that
you
need
to
include
in
your
build
we're
very
lucky
in
that
we
need
exactly
one
external
library
and
that
external
library
is
compiled
as
part
of
cargo
build
and
that's
statically
compiled
into
our
library
through
a
build
rs
file
and
that
luckily
just
works
now
the
problem
is
build.
Rs
is
just
pure
rs
code.
Anyone
could
do
anything
there.
It's
used
to
compile
external
libraries
if
needed,
but
everyone
does
it
differently.
A
Otherwise,
you
also
need
to
ship
all
these
c
dependencies
compiled
and
the
second
tip
is
consider
pre-compiling
the
dependencies
you
have
and
ship
them
to
your
developers
make
them
available.
Somehow,
especially
if
you
have
large
dependencies,
not
everyone
has
the
full
setup
to
also
compile
these,
and
sometimes
it
can
be
a
real
hassle.
But
your
ci
system
probably
already
knows
how
to
compile
for
all
these
different
platforms
that
your
developers
are
also
using
so
just
pre-compile
them
make
them
available
to
the
developers
and
that
integrate
that
somehow
into
your
build
now.
A
One
thing
you
might
now
ask:
so
what
about
the
platform
so
far,
we've
only
seen
it
talk
one
direction
and
that's
because
it
really
only
goes
one
direction:
we're
always
calling
kotlin
we're
always
calling
from
kotlin
into
rust.
We
return
data
on
this
function
call,
but
there
is
never
a
case
where,
from
the
rest
side,
we
call
back
into
kotlin
to
invoke
any
platform
behavior.
A
A
It
also
gets
us
some
information
about
the
system
and
the
application,
like
version
numbers
and
operating
system
versions,
and
so
on.
We
also
rely
on
kotlin
to
do
the
http
or
network
communication
for
us.
We
essentially
tell
the
kotlin
side.
Here's
data
now
use
http
to
upload
it
to
this
server,
and
the
last
thing
we
rely
on
for
for
kotlin
is
time.
A
A
A
Essentially,
you
can
use
idl
files,
that's
interface,
definition,
language
files,
where
you
describe
your
interface,
what
it
should
look
like
and
uni
ffi
will
be
able
to
take
this
generate
the
rust
part,
so
you
can
implement
it
generate
the
ffi
part,
so
it
can
get
called
and
also
generate
the
kotlin
part.
So
you
actually
have
the
integration
into
the
platform.
A
It's
not
there
yet,
but
this
is
something
I
definitely
want
to
help
out
developing
in
the
next
few
months,
and
then
I
talked
about
it
a
couple
of
times
we're
bringing
glean
back
into
firefox
and
desktop.
We
call
this
project
fog,
we're
currently
implementing
and
designing
the
apis.
We
want
to
see
there
like
c
plus,
plus
javascript
and
also
the
rest.
Api
will
be
used
there
and
that's
very
exciting
and
we
hope
to
get
this
into
nightly
and
actually
working
in
the
next
few
months
as
well.
A
A
So
I'd
like
to
see
this
getting
talked
about
more
more
tools
being
developed
for
it
more
documentation
written
around
all
of
this,
and
as
one
last
thing,
because
I
find
this
highly
interesting
and
just
to
plant
the
seed
in
your
head.
Some
of
these
platforms
do
have
ways
to
do
async,
programming
and
now
rust
has
async
programming.
A
A
A
A
A
A
For
us,
it
was
clear
that
we
need
to
share
this
implementation
and
that
we
can
put
a
lot
of
logic
into
this
rust
implementation,
whereas
the
kotlin
parts
are
pretty
much
stateless
and
I
think
that's
where
it
shines
really.
Well,
if
you
know
that
you
need
to
do
a
lot
interaction
between
those
two
sites,
it
might
not
be
optimal
anymore,
so
how
little
or
how
much
you
need
to
write
hard
to
say.
A
So
there's
two
parts
where
we
need
to
do
this.
We
essentially
glean
is
a
global
singleton,
so
we
simply
put
that
in
a
global
static,
that's
behind
a
lock
to
be
kept
alive,
so
it
essentially
lives
for
forever.
That
would
have
been
the
case
if
we
not
done
any
ffi
either
it's
just
that.
We
need
this
global
singleton
to
get
to
the
api.
We
want
to.
A
The
other
thing
where
we
need
to
ensure
things
live.
Are
those
metric
types
that
we
create
on
the
kotlin
site
through
the
ffi,
but
there
we
essentially
rely
on
these
on
this
concurrent
handle
map
from
ffi
support.
I'm
sorry,
the
concurrent
handle
map
and
that's
also
just
a
global
static
where
it
puts
in
the
data
which
ensures
it
lifts
until
we
delete
it
again,
the
place
where
we
need
to
do
some
effort
and
again
that's
wrapped
around
nice
types
for
us
is
returning
streaks.
A
A
Follow-Up
question
from
dowie
on
twitch
again:
would
it
be
more
performant
to
use
bytes
rather
than
a
string
for
exchanging
json
serialized
data?
Yes,
it
would
because
we
can
just
we.
We
wouldn't
need
to
do
the
udf8
check.
Then
again,
json
is
utf-8
data.
So
at
some
point
this
this
would
still
come
up.
We
could
use
one
less
check
there,
but
again
we
don't
care
about
the
performance
there
much.
It's
only
returned
from
test
functions,
so
it
will
never
land
in
the
application.
A
Ariane
on
twitch
asks:
where
does
rust
shine
more
than
any
other
language
in
the
industry.
Oh
that
that
puts
me
in
a
corner.
I
need
to
be
very
careful
here
where
it
really
shines
for
us
is
simply
all
the
safety.
It
brings
us
the
fact
that
we
can
simply
rely
on
on
being
multi-threaded
by
default.
We
we
don't
need
to
take
specific
care
of
that.
It
just
works,
and
the
compiler
will
stop
us
if
it
doesn't.
I
think
that's
one
of
the
major
places
where
it
shines,
especially
in
this
context.
A
We
can't
fully
control
the
kotlin
or
swift
or
python
site,
and
that
might
be
multi-threaded
what
we
need
to
ensure
that
the
internals
in
our
rust
crate
are
thread
safe
and
the
other
thing
is
the
tooling
cargo
is
just
absolutely
amazing,
and
for
us
it
was
very
easy
to
integrate
that.
Well,
not
very
easy.
It
was
considerably
easy
to
integrate
that
into
the
other,
build
sims
as
we
needed
it,
and
other
tooling
is
just
excellent
as
well
in
cargo,
and
this
is
where
I
want
to
see.
Uniffi
going.
A
A
A
A
What
I
can
say,
though,
is
that
our
telemetry
is
slightly
different
from
what
tracing
currently
provides
we're
not
so
much
tracing
across
code
blocks,
but
we're
more
gathering
single
points
of
data
collected
this.
In
my
examples.
In
this
talk
it
was
mostly
counters,
but
what's
much
more
used
is
distributions
of
time
distributions
of
memory.
A
A
A
It
can
be
used
to
implement
all
these
things.
That
needs
to
be
fast
in
the
background
and
the
other
languages
can
provide
the
nice
user
api,
while
cpr
plus
is
the
one
case
where
they
basically
compare
speedwise
but
the
other
languages,
not
necessarily
so.
I
think
this
being
the
language
behind
the
scenes,
essentially
being
the
systems
programming
language
behind
all
these
things,
that's
where
rust
fits
right
in.
A
That's
that's
more
of
a
comment,
but
I'm
still
going
to
read
it
because
it's
essentially
one
of
the
answers
to
the
earliest
questions.
There
there's
a
work
on
open
tracing
and
yeah
for
context.
Crypto
fader
is
one
of
my
colleagues.
It's
not
unreasonable
to
think
of
an
evolution
in
that
direction,
but
for
now
glean
is
focused
on
higher
level
metrics,
not
traces
yeah.
So
this
essentially
sums
it
up.
Currently
we're
focusing
a
lot
of
on
the
higher
level
metrics.
A
As
I
said
before,
we
have
these
distributions,
but
our
distributions
are
specific
to
either
be
timing,
distributions
which
mean
they
measure
a
time
span
or
memory
distributions
which
mean
they
measure
some
form
of
memory.
That
could
be
a
location
that
could
be
disk
space
used
or
memory
used
for
the
javascript
engine
or
resource
like
that.
A
A
The
reason
is
that
so
there
are
multiple
reasons
actually
so
in
firefox
for
android
the
android
browser
we're
building
we're
actually
using
gecko,
that's
the
same
engine,
that's
used
in
firefox
desktop
and
that
engine
brings
its
own
http
stack.
That's
the
whole
implementation
of
the
network.
Communication
is
done
and
on
android
we
actually
want
to
use
this
implementation
of
the
network
stack.
So
we
need
to
pass
it
back
up
through
kotlin
and
then
the
fun
fact
in
firefox
for
android
the
data
actually
gets
passed
back
into
gecko,
which
is
the
c
plus
implementation.
A
A
Android
has
a
network
stack
and
that's
deeply
integrated
with
the
system,
which
also
allows
you
to
schedule
uploads
the
same
on
swift.
You
can
schedule
uploads
and
the
system
actually
does
it
for
you
without
you
needing
to
control
everything
that
actually
also
allows
for
upload.
In
the
background
and
it's
the
same
on
other
platforms,
we
can't
necessarily
rely
on
a
new
network.
Implement
network
stack
implementation
in
rust,
because
the
system
might
use
something
different
to
begin
with.
A
A
Glean
was
developed
at
mozilla,
with
the
specific
needs
that
we
have,
but
we
developed
it
in
a
way.
That's
the
implementation
can
essentially
talk
with
any
pipeline
that
adheres
to
the
same
things.
If
you
watch
our,
if
you
keep
an
eye
on
our
blog,
there
will
soon
be
a
blog
post
about
how
you
can
use
glean
and
not
use
the
mozilla
pipeline
to
get
to
the
data.
So
that's
actually
one
of
the
things
we
want
to
do.
A
Another
common
question
from
jeff
on
youtube:
do
you
have
a
favorite
rust
crate
for
working
with
eros?
I
do
not.
I
hear
this
error
is
pretty
good.
I
actually
ripped
out
all
usage
of
failure
in
our
code
base
and
part
of
our
dependency
tree,
because
the
overhead
it
introduced
was
bigger
than
just
implementing
the
enums
ourselves
and
then
implementing
error.
A
A
We
went
to
great
length
to
ensure
that
under
correct
use-
and
like
most
of
it
is
guaranteed
by
rust.
You
can't
run
into
errors.
The
errors
you
can
run
into
are
all
handed
internally.
If
we
can't
write
to
the
database
for
whatever
reason
we
still
don't
want
to
crash
any
application
that
we're
integrating
with.
If
you
can't
write
to
the
database,
then
so
be
it,
the
application
still
runs.
A
If,
however,
we
we
try
to
write
into
a
metric
type
and
some
of
the
types
don't
match
or
some
integer
overflows
or
something
like
that,
we
actually
use
our
own
system
to
report
these
errors.
So
we
see
them
in
the
data.
So,
if
anything
is
is
wrong
with
the
data
we're
trying
to
record,
we
record
an
error
in
our
own
data,
and
then
we
see
it
so
we're
never
exposing
any
errors
from
the
ros
code
over
the
ffi.
So
we
don't
need
such
a
crate
at
the
moment.
A
A
It
cost
me
quite
some
headache
because
of
some
things
it
does
essentially,
the
way
features
are
handled
still
has
a
lot
of
problems
and
that
didn't
really
cause
problems
directly
for
glean,
but
integrating
lean
into
a
project
as
large
as
firefox
causes
problems
because
of
the
way
cargo
uses
features.
Luckily,
for
me,
this
is
actually
fixed
and
hopefully
getting
stabilized
with
the
next
cargo
release.
A
A
That's
the
current
design
of
glean
and
that
works
for
browser
type
applications
quite
well
be
that
on
mobile
or
desktop
the
javascript
api
inside
firefox
has
a
lot
of
direct
integration
with
c
and
c
plus
and
rust
part
of
firefox.
So
we
can't
use
webassembly
there
because
we
still
need
to
call
into
the
native
code
anyway
for
websites.
I
still
can
see
some
form
of
glean
being
used,
but
I
don't
see
the
current
glean
design
working
out
for
a
website,
because
in
a
website,
even
in
a
single
page
application,
you
have
this.
A
You
don't
have
this
long
running
thing
you
at
potentially
any
time
this
tab.
Your
website
could
just
reload,
you
don't
have
any
real
persistent
storage.
So
you
can't
store
that
forever
offline,
but
you
need
constant
communication
with
the
server.
The
way
we
bundle
up
metrics
into
pings
also
doesn't
lend
itself
very
good
for
a
website
on
a
website.
If
you
need
some
statistics
or
metrics
about
your
data,
you
probably
want
to
send
them
out
quickly,
so
you
send
out
small
packets
and
you
send
them
off
before
the
user
leaves
the
website
again.
A
A
A
So
I
think
the
one
of
the
interesting
questions
here
was
from
from
dowie
on
twitch
about
what
was
the
effort
to
ensure
rust
objects
live
longer
than
rust.
Usually
would
do
I
answer
that
we
we
don't
need
to
do
much
for
that.
We
rely
on
our
other
tooling
to
do
that,
but
there
are
ways
and
rust
to
do
this
on
your
own
by
just
allocating
stuff
and
then
forgetting
about
it
and
returning
pointers.
So
that
was
definitely
one
of
the
good
questions.