►
Description
One year ago, my team released Krustlet, a Kubernetes Kubelet implementation for running WASM modules written in Rust. Since then, we've spent plenty of time out on the frontier, implementing full Kubernetes functionality, all in Rust. In this session, we'll cover why we chose Rust and how WASM and Rust work together. Using examples from Krustlet, we'll also review the pros and cons of using Rust for writing software for the cloud and address how it compares to languages like Go.
Thomas on Twitter: https://twitter.com/_oftaylor
Rust Linz on Twitter: https://twitter.com/rustlinz
On the web: https://rust-linz.at
Submit your talk: https://sessionize.com/rust-linz
A
A
First
off
I'm
a
crestlet
and
helm
core
maintainer
and
we'll
talk
a
little
bit
about
a
little
bit
if
you're
at
all
in
the
cloud
native
or
cloud
software,
space
you've,
probably
at
least
heard
of
helm
and
that's
a
package
manager
for
kubernetes.
I've
been
doing
kubernetes
and
container
things
for
a
long
time.
So,
basically,
since
the
beginning
of
docker
and
for
quite
a
while
with
kubernetes
itself,
I
came
to
rust
by
way
of
go,
which
makes
a
lot
of
sense.
A
A
You
want
to
tweet
about
something
or
ask
any
questions
or
or
make
fun
of
my
slides
whatever
you
want
to
do
so,
if
you
can't
tell
I'm
I'm
pretty
straightforward
and
frank
with
everything,
I'm
going
to
be
completely
honest
during
this
talk
about
the
various
strengths
and
weaknesses
of
rest
in
cloud
development,
but
my
opinion
is
still
just
my
opinion.
So
keep
that
in
mind.
I
have
been
doing
this
whole.
This
whole
cloud
native
thing
for
for
a
while.
A
So
hopefully
that
gives
you
some
confidence
that
I'm
not
totally
making
this
up
for
you.
So
yeah,
that's
just
a
little
bit
about
who
I
am
now.
Let's
go
over
what
I'm
going
to
talk
about
today,
so
first
off,
I'm
gonna
give
a
brief
intro
into
our
projects
and
what
wasm
is
and
then
answer
the
question
well,
but
why?
Why
are
we
doing
this
and
then
I'm
gonna
talk
about
using
rust
and
cloud
development
with
good,
bad
and
ugly?
Now
I
know
we
kind
of
have
a
mixed
crowd
here.
A
Some
are
more
rust
newbies.
Some
are
very
experienced
with
rust.
Some
are
experienced
with
cloud
software
and
some
are
not
so.
This
is
going
to
be
focused
on
cloud
software
and
it's
I'm
going
to
be
talking
about
some
things
that,
if
you're
very
familiar
with
the
lanes,
you'll
be
like
oh
yeah.
I
know
that,
but
there
might
be
some
other
things
in
here.
That
you'll
also
be
able
to
pick
up
on
and
learn
some
things.
So
this
is
meant
to
be
a
the
whole
thing
is
meant
to
be
a
knowledge
sharing
presentation.
A
A
I
want
to
make
sure
that
we
can
cover
the
things
that
are
of
interest
to
people
here
and
then
at
the
end,
we're
also
going
to
have
a
little
bit,
that's
kind
of
a
tongue-in-cheek
joke
about
being
a
cage
fight
between
rust
and
go,
and
that's
a
question
that
people
ask
us
a
lot.
So
I
I
threw
that
in
there
as
a
little
bonus
content,
so
we
can
cover
it
about
so
yeah.
A
A
So
let's
go
ahead
and
intro
the
projects
that
we
have
and
first
to
understand
all
the
projects
that
I'm
going
to
kind
of
use.
As
a
backdrop
here,
I
need
to
mention
what
web
assembly
is.
The
webassembly
is
known
as
wasm
and
if
you're
not
familiar
with
wasm
wasm
is
a
compiled
binary
that
can
be
run
through
run
in
a
browser
through
javascript,
except
that's
its
main
use
right
now,
and
so
it
allows
you
to
have
these
the
speed
of
compiled
code
while
still
running
in
something
like
a
browser
environment.
A
A
So
here
are
the
projects.
Now
these
projects
are
what
I'm
going
to
be
drawing
from,
as
I
go
over
the
different,
the
different
parts
of
of
rust
and
now
all
these
are
real
world
projects
that
are
where
there's
a
fairly
large
code
base
involved
with
various
servers,
clients,
code
machinery,
all
the
things
you'd
expect
from
a
project
that
deals
with
distributed
systems
or
cloud
software.
A
A
Now
all
of
these
projects
are
open
source,
so,
if
you're
interested
feel
free
to
contribute
code
by
bug
reports,
whatever
it
might
be
through
through
these
projects,
I'm
not
really
going
to
give
a
super
detailed
intro
to
the
wazi
http
project,
but
I
might
mention
it
in
context
of
other
things.
I
just
wanted
to
drop
the
link
there
so
that
people
can
can
take
a
look
at
it,
so
these
are
all
under,
and
I
guess
that
I
just
realized.
I
forgot
to
introduce
that
so
deus
labs
is
my
team
at
microsoft.
A
I
work
for
microsoft,
but
we
work
my
team
works
primarily
all
in
the
open
source
space
with
with
these
kinds
of
technologies.
So
that's
that's
where
that's
from
so
first
off
crustlet,
now
that
first
line
that
first
bullet
looks
ugly,
but
that
explains
where
the
name
comes
from.
It
means
it
stands
for
kubernetes,
rest
kubelet
if
you're
not
familiar
with
kubernetes,
the
kubelet
is
the
thing
that
runs
on
a
node
inside
of
a
kubernetes
cluster,
so
it
is.
Its
primary
purpose
is
to
run
wasm
modules.
A
So
modules
are
the
name
of
the
compiled
binaries,
so
it
runs
these
wasa
modules
within
a
within
kubernetes.
Now
we
have
inside
of
this
a
idea
of
providers.
Now
this
comes
from
another
project
called
virtual
kublet.
We
stole
this
kind
of
idea
of
having
a
provider,
meaning
that
you
can
implement
any
sort
of
thing
that
you
want
to
we've
heard
some
people
are
trying
to
do
some
stuff
with
systemd
we've.
Had
people
try
to
re-implement
container
support
you
can
you
can
implement
anything
you
want
with
with
these
providers?
A
A
So
these
are
that
you
don't
have
to
remember
all
these
concepts,
but
that's
like
you
might
see
that
some
of
that
terminology
and
things
as
you
look
around
and
it
basically
allows
people
to
write
whatever
sort
of
kublet
they
want
within
rust.
Now
inside
of
the
project,
there's
actually
three
crates
that
we
export.
One
of
them
is
kublet,
which
is
the
actual
thing
that
runs
the
the
kubelet
component.
A
We
have
oci
distribution,
which
is
the
which
is
a
partial,
open
containers
initiative
like
the
open
containers,
initiative
interfaces
that
implementation,
and
then
we
have
a
project
called
crater
with
a
link
to
what
that
is,
but
it's
a
it's.
A
fully
featured
compile-time,
checked
state
machine
in
rust
for
for
building
kubernetes
operators
and
other
things
which
is
used
inside
of
the
creslip
project.
A
Next
up
we
have
bindle,
so
bindle
is
an
aggregate
object,
storage
system.
The
easiest
way
to
explain
this
is
a
silverware
drawer,
a
flatware
drawer.
So
if
you
have
your,
you
generally
have
a
drawer
that
contains
your
forks,
your
spoons,
your
knives
and
every
and
all
the
little
fancy
things
you
need
for
more
fancy
dinner
or,
if
you're,
if
you're
doing
also,
you
generally
have
so
many
different
utensils
in
there
and
so
for
breakfast.
You
might
only
need
something
like
a
spoon
but
for
a
fancy
dinner.
A
You
might
need
a
spoon
fork,
a
knife
and
then
like
a
chilled
salad
fork
or
something
else.
Now
all
of
these
things
are
related.
You
gen
most
people
generally
don't
have
a
separate
drawer
for
every
type
of
utensil,
and
so
the
idea
was
that
a
lot
of
things
in
the
cloud
name
space
they
don't
allow
you
to
sh
to
put
related
objects
all
together
and
so
in
taking
this
example
of
the
silverware
drawer.
A
If
I
want
to
select
a
certain
number
of
web
assembly
modules
that
I
want
to
use
depending
on
what
kind
of
system
I'm
on
and
how
much
processing
power
I
have,
this
allows
me
to
select
the
specific
set
of
binaries
that
that
we
need
that
you
need
for
a
project.
So
the
first
use
case
this
was-
and
we
created
it
for-
was
enabling
our
our
wasm
and
wazi
projects,
the
idea
being
that
we
can
pull
like.
I
said
those
modules
and
and
then
use
them
the
way
we
want
them
to.
A
However,
there's
there
could
be
really
some
really
other
interesting
use
cases
for
this.
If
it
is
interesting
to
you
reach
out
to
us
on
github,
but
it
also
turns
out
we
kind
of
stumbled
on
this,
that
it
could
be
useful
for
securing
software
supply
chains.
Bindle
is
strongly
typed
and
versioned,
so
each
each
there's
basically
a
manifest
of
what
objects.
It's
called
an
invoice
in
in
bindle.
A
Each
of
these
things
are
signed
by
the
person
who
creates
it
and
the
server
that
hosts
it,
and
it
must
have
an
exact,
specific
sember
version.
So
this
is
just
an
interesting
project
that
that
I'll
show
some
code
from
as
well
but
is
tied
into
this
web
assembly
module.
We
also
have
this
this
wagy
project
or
raggy
project,
so
it
stands
for
webassembly
gateway
interface.
And
yes,
you
read
that
right.
A
It
is
a
cgi
implementation
that
basically
allows
wazi
modules
to
act
as
http
handlers,
so
you're
able
to
to
compile
it
whatever
your
code
is
doing
down
to
webassembly
and
then
have
it
act
as
a
handler
for
a
specific
http
endpoint.
So
this
was
just
another
way
we
went
around
enabling
http
for
wazi
and
bindle
can
be
used
with
waggy
to
pull
the
proper
modules
down
or
you
can
upload
modules
we're
still
building
that
project
out,
but
that's
another
one
that
we
have
so
we
get
to
this.
But
why
like?
Why?
A
Why
did
we
write
all
these
things
in
rust?
Why
did
we
choose
wasm?
Why
did
we
integrate
this
with
kubernetes?
Why
did
we
even
mess
around
with
cloud
stuff
at
all?
Isn't
rus
a
systems,
programming,
language?
Those
are
the
questions
that
people
often
ask.
So,
let's
dive
into.
Why
so,
first
off,
let's
talk
about
the
wasmanwasi
side
of
things
I
like
to
tie
this,
but
wait.
I
already
have
containers.
Why
do
I
need
something
else?
So,
first
off
these
two
are
fairly
self-explanatory.
So
there's
more
security,
waza
modules
run
in
a
completely
sandboxed
environment.
A
You
have
to
explicitly
grant
permission
for
them
to
be
able
to
access
anything
density,
we're
talking
about
an
order
of
magnitude
smaller
in
size,
so
you
can
have
a
you
can
have
a
if
you
have
a
well-crafted
docker
image,
you're
talking,
probably
20,
megs
10
megs,
depending
on
what
kind
of
thing
you
have
in
there.
If
you,
if
you
built
your
containers
right,
you
can
generally
have
or
built
your
wasa
modules
right.
A
You
can
generally
have
them
between
one
to
five
megs,
depending
on
what
they're
doing,
which
is
much
smaller
and
also
the
the
things
needed
to
run
them.
You
don't
need
a
full
docker
runtime,
you
don't
need
any
of
that.
You
just
have
to
have
a
wazi
compatible
runtime
that
can
run
these
things.
So
it's
a
lot
easier
to
run
these
in
other
places
and
and
to
pack
them
more
tightly.
A
A
Just
just
a
point
here,
this
isn't
meant
to
completely
supplant
docker,
but
because
there's
certain
workloads
that
are
are
never
going
to
be
worth
porting
to
wasm,
even
if
we,
even
if
everything
was
in
place,
but
this
is
where
we
get
to
the
it
is
actually
run
everywhere
to
an
extent
we
like
to
say,
if
you've,
if
you've
been
in
the
cloud
space
at
all
and
you've
used
docker,
we
like
to
say:
oh
well,
dockers,
work
anywhere,
and
it
really
isn't.
If
we're
just
being
honest
with
ourselves,
it's
a
linux
technology.
A
Now
there
are,
there
are
windows,
containers
but
they're,
very
different
from
a
linux
container.
They
aren't
the
same
thing
if
you
have
an
nginx
container,
that's
running
somewhere
on
a
linux
server.
You
cannot
run
that
exact
same
container
on
windows
that
isn't
also
running
a
linux
vm.
So
it's
not
actually
run
everywhere,
and
you
contrast
that,
with
with
webassembly-
and
it's
closer
to
this,
this
dream
of
having
a
universal
binary.
A
So
I
can
compile
a
webassembly
module
on
my
mac
that
I
have
right
here
and
it
will
run
on
my
windows
machine
out
there.
It
will
run
on
a
linux
server
in
the
cloud
it'll
run
on
a
raspberry
pi,
it's
going
to
run
everywhere,
and
that
is
very,
very
powerful
and
helpful
so
between
the
size
shrinking
and
that
it's
it's
super
useful
and,
like
I
said
you
have
this,
this
overhead
of
docker
and
other
container
runtimes.
A
So
that's
one
of
the
big
reasons
we
actually
have
crestlet
is
to
enable
those
kind
of
people
to
to
try
that
out.
So
the
next
big
thing
here
is
rust
and
wasm
are
great
friends.
So
if
you,
if
you've
toyed
around
with
webassembly
at
all
you'll
you'll
you'll,
see
it
really
quickly,
but
a
lot
of
the
tooling
in
the
wazi
space
is
actually
written
in
rust
and
it
has
a
built-in.
A
So
another
thing
that
answers
kind
of
the.
Why
here
is
about
kubernetes
in
the
cloud
so
for
many
people,
especially
those
who
especially
late
adopters
in
terms
of
companies,
that
kubernetes
is
the
cloud
now.
I
don't
necessarily
agree
with
that.
I
don't
think
that
should
be
the
thing,
but
whether
I
like
that
or
not
kubernetes
and
containers
have
become
synonymous
with
running
applications
in
the
cloud.
A
Most
people
who
have
migrated
to
or
are
currently
migrating
to,
the
cloud
have
interacted
with
kubernetes
in
some
way,
so
we
created
crestlet
as
a
way
to
allow
people
to
try
web
assembly
in
a
familiar
environment.
So
you
can
start
to
see
how
all
this
adds
up.
We
have
rust,
which
has
great
support
for
webassembly
and
then
we're
tying
this
into
into
the
cloud
and
crestlet
was
kubernetes.
A
Was
the
good
place
to
give
somebody
give
people
a
familiar
place
to
try
these
things
out,
but
also
we
discovered
rust
is
a
really
great
fit
for
working
with
kubernetes
and
other
cloud
applications
with
similar
apis
and
that
that's
where
I'll
mention
this,
and
so
I
know
we're
getting
here
and
I'm
sure
some
of
you
are
asking
like.
Oh
my
gosh
taylor,
you
are
at
a
rest,
meetup
and
you're
just
barely
getting
to
rest,
and
I
get
that.
A
But
all
of
this
stuff
is
really
important
to
understand
how
we
use
rust
and
cloud
development
and
and
why
it's,
what
its
strength
are
and
what
its
weaknesses
are.
So
here's
just
kind
of
an
overview
of
the
things
that
we've
seen
in
rest.
These
are
the
high
level
reasons
why
we
chose
rest,
so
the
first
one
is
safety,
which
is
one
of
the
oft
touted
features
of
rust.
A
To
quote
one
of
my
co-workers,
when
we
were
kind
of
compiling
some
of
the
information
around
this,
he
literally
sent
me
an
all
in
all
caps.
No
damn
null
pointers,
because
safety
is
required
and
unsafety
as
I'll
call
it
is
is,
is
explicitly
called
out
with
the
unsafe
keyword.
I
can
easily
grep
through
code
and
find
where
all
of
my
unsafe
calls
are,
and
so
I
know
exactly
where
something
like
a
null
pointer
or
memory
issue
can
happen
because
of
rest,
strict
ownership
rules
that
keep
everything
inside
of
in
very
safe.
A
A
Have
you
scratching
your
head
a
bit,
and
so
I'll
explain
more
about
that
in
the
next
section,
but
basically
rust
as
a
language
makes
it
very
very
easy
to
design
flexible
and
extensible
apis,
which
isn't
necessarily
true
for
all
other
languages
that
are
common
in
the
cloud
software
space,
we're
talking,
go
and
python
and
some
of
those
other
those
languages.
It's
a
lot
harder
to
design,
flexible
and
extensible
apis.
B
A
A
What
should
you
watch
out
for
when
you're
starting
your
own
new
project,
and
so
these
are
all
based
on
real
experiences
and
code
from
our
projects,
now
that
these
projects
are
a
little
bit
bigger
than
just
kind
of
toy
projects
that
we
do
on
the
side
now,
some
of
what
I'm
going
to
talk
about
here
can
be
found
in
the
blog
post.
I
have
linked
on
on
this
slide.
A
This
is
a
blog
post
I
wrote
about
a
month
ago,
but
we're
going
to
be
diving
into
more
details
and
other
things
than
that's
just
in
that
blog
post
and
you'll
be
able
to
ask
me
any
follow-up
questions
here
at
the
end,
so,
let's
just
dive
right
in
so,
let's
start
off
with
the
good.
So
this
is
not
just
about
the
good
things.
This
is
about
like
how
things
went
with
our
projects
and
how
we,
how
we
felt
rust,
really
showed
its
power.
A
A
Dref
is
a
really
interesting
one
to
us,
because
you
can
basically
use
that
object
as
the
underlying
type.
If
you're
not
familiar
with
that.
That's
exactly
what
happens
when
you
use
the
owned
string.
Type
most
of
the
methods
are
actually
implemented
on
the
underlying
borrowed
string,
so
ampersand
str,
most
of
them
are
implemented
on
that
and
not
on
the
the
owned
string
type
but
you're
able
to
access
both
methods.
Because
of
the
draft
trait
here
is
an
example
from
from
our
bindle
sorry,
this
is
bindle.
A
A
Now
the
other
thing
that's
really
nice-
and
you
can
see
this
here
is
we
have
the
idea
of
traits
can
declare
associated
types
your
you
can
still
have
generics
even
in
an
interface
context.
So
right
here
you
see
I
error
so
there
I
was
able
to
specify
a
type
that
implements
the
error
trait
in
rest
and
so
because,
because
those
were
all
tied
all
tied
together,
I
was
still
able
to
use
this
very
generic.
Try
into
interface
with
my
own
custom
error
type
and
that's
very,
very
useful.
A
So
the
other
thing
to
think
about
this
is
if
you're
familiar
with
a
lot
of
cloud
apis
and
especially
kubernetes.
You
have
you
have
a
types
that
are
all
very
similar,
but
you
can
perform
different
actions
on
them
and
so
in
go
which,
which
most
the
kubernetes
libraries
are
are
written
in.
You
have
a
separate
interface
for
each
kind
of
type
of
api
type
in
rust,
there's
actually
just
a
single
generic
type
and
client
that
can
access
any
kubernetes
style
objects,
which
is
so
useful
and
cleans
up
code
so
well.
A
The
other
good
thing
we
found
is
enums.
They
are
very,
very
helpful,
especially.
We
found
in
error
handling
enum's
changed
how
most
of
us
think
about
errors,
because
rusty
numes
are
not
just
single
values
right
they
can.
They
can
carry
associated
data
with
them,
and
each
variant
can
have
a
different
data
structure,
they're
kind
of
like
discriminated
unions
from
other
languages,
and
you
can
work
with
these
different
cases
using
pattern
matching
and
so
because
they're
also
a
full-blown
type.
You
can
then
also
implement
methods
on
that
type
or
traits
for
that
type.
A
So
the
really
the
the
big
value
here
is
that
you
don't
have
to
bundle
a
bunch
of
possible
cases
into
a
single
type
to
pass
into
or
return
from
a
function
and
working
with
the
cases
is
safe,
because
the
compiler
tells
you
if
it's,
if
you
haven't
matched
everything
and
also
there's
no
there's
no
need
for
optional
fields.
Here
that
might
only
apply
to
certain
certain
cases,
and
so
this
actually
this
allows
for
code
or
it
encourages.
A
I
should
say,
code
that
processes
enums
to
be
like
have
very
clear,
regular
layouts,
and
it
makes
for
some
very
beautiful
code
and
engineering.
So
right
here,
you
can
see
that
I
have
an
example
error
type.
This
is
kind
of
a
paired
down
air
type
from
bindle
and
I'm
able
to
have
totally
different
data
associated
with
each
with
each
type
and
then,
when
I
go
down
below
I'm
able
to
unwrap
and
do
things
with
that
data
very
very
well.
A
This
is
very
helpful
in
really
anything
that
involves
like
an
api
or
network
call,
because
there
can
be
so
many
things
that
fail.
There
can
be
something
with
the
network
that
fails.
There
can
be
something
with
the
service
is
offline.
There
could
be
something
where
you
have
an
invalid
request
or
the
request,
and
it
can
tell
you
exactly
why
if
the
request
needs
more
data,
all
these
things
are
very
common
interactions
and
rust
has
easily
been
the
best
way
to
handle
those
kind
of
situations
in.
A
In
our
experience
with
things
like
enumes
and
other
types
of
error
handling,
I
mean
you
can
see
too
because
enums
can
hit.
It
can
also
contain
generics.
This
is
one
from
crestlit
that
allows
us
to
specify
a
very
specific
state
type
when
you're
transitioning
from
one
state
to
the
next,
and
that
is
that
generic
type
added
on
to
all
the
power
of
the
enum
is
very,
very
helpful
and
very
flexible.
A
So
the
other
thing
we've
run
into
that
is
extremely
useful
inside
of
at
least
kubernetes,
and
I
think
a
lot
of
different
cloud
applications
is
macros.
So
macros
can
be.
Writing.
Macros
can
be
a
little
bit
finicky
if
you
haven't
written
one
before,
but
let's
just
use
this
example
to
walk
through
what
we
were
able
to
do
here,
which
is
all
which
is
useful
for
cloud
software.
So
in
kubernetes
there's
this
idea
of
something
called
a
custom
resource.
A
This
is
created
at
runtime
using
them
using
the
macro
as
a
compile.
So
this
custom
resource
derived
allows
you
to
go
through
and
specify
just
a
few
arguments
saying:
here's
what
it
should
be
and
then
the
data
that
we
actually
care
about
inside
of
our
inside
of
our
rest
program
and
then
derive
the
whole
implementation
for
it
automatically.
A
And
you
also
see
in
there
the
very
classic
30,
serialize
and
deserialize,
which
to
us,
is
just
absolute
magic
compared
to
many
other
languages,
because
you
can
derive
these
implementations
and
then
anything
that
implements
the
serdi
data
model.
You
end
up
being
able
to
then
just
because
we've
derived
these
be
able
to
serialize
it
to
any
type.
You
want
yaml
tamil
json,
there's
more
types
than
that.
A
This
is
all
just
a
drive
block
that
if
we
include
all
this
formatting
and
stuff
to
make
it
look,
nice
is
maybe
10
lines
of
code,
and
that
is
that
is
extremely
clean
code
and
easy
to
kind
of
figure
out.
What's
going
on,
so
that's
something
that,
as
you
come
into
rust,
either
as
a
newbie
or
as
someone
doing
cloud
software
like,
I
think
we
find
macros
useful
anywhere
in
rust.
But
there
is.
A
B
Can
I
interrupt
you
for
a
second,
you
asked
me
to
relay
questions
and
I
wasn't
fast
enough
to
be
honest.
There
is
a
question
concerning
enums
matthias
is
asking
whether
there
is
any
specific
reason
why
you
didn't
use
a
library
for
error
handling.
He
thinks
that
this
error
would
really
reduce
the
code
needed
any.
A
Thoughts
on
that
good
question,
so
actually
this
is
I
paired
that
off
of
here,
just
to
keep
it
simpler.
This
is
using
this
error
underneath
the
hood,
so
we
have
derives
and
things
under
here
that
are
sorry.
We
have
the
derive
error
and
then
we
also
have
the
error
type.
The
error
tag
on
each
enum
variant,
and
so
this
actually
takes
it
and
and
prints
it
out.
A
The
handle
error
was
also
a
simplified
case
of
of
what
it
was
doing,
we're
actually
doing
some
like
logging
and
other
things
inside
of
the
handle
error
function,
but
the
example
was
simplified,
so
it
wouldn't
completely
take
up
the
whole
slide
or
two
slides.
So
yes,
that's
a
good
point
and
good.
Thank
you
for
reminding
me
to
bring
that
up.
A
A
A
It's
very
helpful
to
people
in
the
language,
and
I
know
that
when
I've
been
helping,
people
come
into
these
projects
and
start
working
on
it,
they're
able
to
read
and
understand.
What's
going
on
with
error
handling
very
very
easily,
so
this
block
right
here
is
a
little
gnarly,
but
this
kind
of
shows
there's
a
the
whole
suite
of
like
chainable
filters
maps,
splitting
zipping
methods
similar
to
how
link
and
functional
programming
languages
handle
collections
along
with
the
all
powerful
collect
method.
A
So
basically,
this
is
a
fan
out
and
fan
in
in
20
lines,
so
that
is
very,
very
helpful,
especially
when
you're
doing
some
of
the
code.
That
happens
a
lot
inside
of
inside
of
cloud
computing
and
not
just
cloud
computing,
but
anywhere
really.
But
a
lot
of
what
we
have
to
do
is
kind
of
massage
data
from
one
source
to
be
able
to
use
it.
A
And
these
these
chainable
filtering
and
mapping,
and
all
that
just
makes
it
so
easy
to
to
massage
that
data
and
get
it
into
the
format
we
need
to
be
able
to
either
return
or
or
to
use
that
data
that
we're
getting
so
like.
I
said
the
block
still
gnarly,
but
we
do
a
lot
here
in
a
very
small
amount
of
space.
A
A
We're
able
to
select
only
specific
features
of
some
generated
api
objects.
We
can
add
additional
features
in
or
make
them
optional,
so
that
we
only
enable
them
when
we
need
it.
We
can
also
work
on
a
crate
locally,
but
when
it
gets
pushed
it
gets
pushed
with
the
right
version.
That's
like
the
oci
distribution
line
there,
which
is
all
quite
useful,
and
the
other
thing
that
I
can't
say
enough
about
is
the
rest
community.
So
the
rest
community
is
absolutely
amazing.
It's
not
only
just
inclusive,
but
it's
also
very
responsive
and
helpful
for
newcomers.
A
A
recent
example
of
this
is
we're
having
a
deadlock
issue
in
crestlet
with
tokyo
and
all
the
core
maintainers
of
crusade
had
just
been
like
working
on
it
for
a
week
going
what
is
going
on,
and
so
we
asked
a
question.
Well,
I
went
over
and
asked
a
question
on
the
tokyo
discord
channel
and
one
of
the
core
maintainers
responded
very
nicely
in
less
than
five
minutes,
and
then
not
only
did
they
provide
some
helpful
useful,
very
helpful
and
useful
information
to
me
to
be
able
to
troubleshoot.
A
They
also
came
in
and
went
to
the
pr
and
dropped
in
a
few
more
suggestions,
and
this
isn't
the
only
time
I've
seen
that
kind
of
behavior.
It's
something
I
see
all
the
time
in
the
rest.
Community
and
you'll
never
be
made
to
feel
like
you're
asking
some
sort
of
stupid
question.
People
will
always
respond
with
kindness
here,
and
so
I
I
really
really
enjoy
the
rest
community.
A
A
So
let's
kind
of
go
over
some
of
the
things
we
consider
like
the
bad
and
ugly
I'm
going
to
kind
of
gloss
over
some
of
these.
I
don't
want
to
spend
too
long,
but
let's
just
talk
about
some
of
the
things
you
need
to
be
aware
of
that
we've
kind
of
run
into
with
our
projects,
so
first
off,
is
docs
and
clarity.
So
we've
noticed
an
interesting
pattern
in
a
lot
of
our
crate
dock
in
live
in
lots
of
different
crates
and
their
documentation.
A
Sometimes,
if
something
is
copying
under
the
hood
or
does
the
file
handle
get
flushed
when
I
call
this
function
and
a
lot
of
those
things
aren't
very
well
documented
and
because
of
this
emphasis
on
zero
cost
abstractions
we
just
kind
of
assume.
Sometimes
we
have
to
handle
it
or
don't
handle
it,
and
so
there
is
not
documented
very
well.
A
So
this
happened
to
us
in
crestlet
with
stack
overflows
on
windows,
which
I
couldn't
put
here
either
it's
too
large,
but
we
were
basically
crestlet
runs
a
whole
bunch
of
futures,
they're
all
running
different
tasks
for
the
system
to
work
properly
and
what
what
happened
is
when
we
started
trying
to
get
it
to
work
on
windows.
It
would
just
stack
overflow
and
we're
like
well
what's
going
on
here.
Well,
it
turned
out
in
our
in
our
newbie
rest
brains.
A
So
once
we
figured
that
out,
we're
able
to
pin
it
to
the
heap
because
we're
fine
with
using
things
from
the
heap,
and
so
that's
just
something
to
keep
aware
of
now
up
here
on
in
the
slide
is
an
example,
that's
related,
but
slightly
different,
so
as
users
when
we're
trying
to
find
out
how
we
can
customize
behavior
by
implementing
a
trait,
we
end
up,
jumping
through
like
a
million
different
functions.
Looking
at
all
the
trait
bounds
before
we
can
figure
out
what
we
need
to
implement
and
oftentimes,
these
traits
are
in
other
crates.
A
So
this
is
an
example
from
the
absolutely
wonderful
tonic
crate,
which
allows
you
to
use
grpc
connections
across
and
use
grpc
files
to
generate
the
proper
code
for
it
as
well.
But
you
look
here,
there's
this
make
connection
uri
and
then
you
have
two
associated
types
that
are
related
to
it
that
need
to
be
send
in
static
but
like
what
are
those
types?
What
has
to
be
implemented?
So
you
would
click
through
to
make
connection.
It
has
its
own
things,
but
there's
also.
A
It
also
has
to
implement
like
async,
read
and
async
right,
and
you
just
go
down
this
big
chain,
and
so
there's
like
three
or
four
distinct
bounds,
two
with
different
traits.
It
turned
out
that
all
with
all
that
was
actually
needed
was
the
code
right
below,
which
is
super
simple,
and
we
found
that
in
the
examples
directory.
A
But
as
someone
who
was
looking
through
this
trying
to
figure
out
which
traits
and
things
I
needed
to
implement
the
first
time,
it
was
very
difficult
for
a
for
a
first-time
rest
person
figuring
this
out.
So
just
make
sure
that
you
document
link-
and
please
note
that
right
here-
these
are
the
old
docs
that
we
saw
they
actually,
since
we,
since
I've
written
this
and
we've
talked
about
it,
they
actually
added
in
a
link
to
the
example
of
how
to
how
to
implement
something
for
this
function.
A
Another
thing
to
be
aware
of
that
we've
run
into
in
a
lot
of
our
projects
is
that
the
rust
in
the
rust
ecosystem
for
at
least
the
cloud
computing
and
like
http
things,
there's
still
a
lot
of
missing
features.
So
one
thing
that
we
ran
into
recently
is
we
found
out
there
isn't
much
support
for
multi-part
content
types
in
http
requests,
except
for
form
data.
So
this
is
not
like
a
complaint
against
any
specific
developer
that
create.
A
We
think
this
is
more
due
to
rust,
still
being
newly
popular
and
its
primary
use
case
being
systems
programming,
but
in
in
this
cloud
space
and
really
application
developers
in
general,
there's
there's
just
some
gaps
in
the
functionalities.
We'll
talk
about
the
async
space
in
just
a
second,
but
there's
a
lot
of
things
with
http
that
aren't
completely
there.
You
have
different
http
library
choices
instead
of
one
or
two
de
facto
ones
or
built-in
support.
A
A
Now,
that's
all
built
in
the
standard
library
for
unix
and
it's
not
in
the
standard
library
for
a
good
reason,
because
russ
supports
back
to
something
like
windows,
8,
and
this
wasn't
added
until
windows
10.,
but
there's
no
maintained
crates
to
do
this
in
an
async
way.
So
this
is
not
a
problem
with
rust
itself.
I'm
not
complaining
about
this
itself
or
the
people
who
write
these
things.
But
if
you
look
at
all
these
unholy
things,
we
had
to
do
with
the
code.
Just
don't
ask
me
what
that
reinterpret
cast
is
doing.
A
You
don't
want
to
know,
but
we
had
to
go.
We
had
to
go
implement.
Basically,
all
the
the
reading
and
clear,
read,
ready
and
add,
read,
ready
and
all
that
stuff
in
from
someone
else's
crate
and
kind
of
copy
and
do
all
this
stuff,
because
it
wasn't
there
so
you're
gonna
run
into
gaps
and
it's
a
perfect
place
where
you
can
contribute
back
to
the
community.
If
you
find
that
interesting.
A
Another
thing
is
that
people
like
to
complain
about
the
learning
curve
of
rest.
Now.
My
personal
opinion
on
on
this
is
that
russ
does
have
a
bit
of
a
logarithmic
learning
curve,
like
what's
shown
here,
that
there's
a
very
steep
initial
learning
period
of
about
a
month,
but
it
levels
out
pretty
quickly
and
in
our
team's
experience
after
about
a
month,
a
developer
is
just
as
productive
as
they
were
previously
doesn't
mean
you're
still
learning
not
not
still
learning.
A
It
just
means
that
you're
able
to
be
as
productive
as
you
were
before,
but
now
that
we've
been
releasing
several
different
crates
and
things
we
there's
a
few
more
bumps
in
the
road
to
be
aware
of
in
the
bumps
in
the
learning
curve.
I
should
say,
as
you
start
writing
your
own
crates
and
doing
things.
One
of
them
is
that
there's
a
learning
curve
around
designing
apis,
particularly
when
working
with
an
api
that
uses
generics
or
trait
bounds,
to
make
it
easy
for
public
consumption.
A
A
You
just
have
to
look
at
the
get
history
of
crestlet
to
see
all
the
fixing
we've
done
there
with
some
of
those,
and
this
is
where,
if
you
have
experiences
and
things
to
create
any
training,
material
or
documentation,
this
could
help
ease
that
part
of
the
learning
curve,
because
it
was
something
we
didn't
really
anticipate
coming
in,
but
now
that
we've
done
a
lot
of
it.
That
is
definitely
part
of
learning
curve
that
not
many
people
mention
you
just
have
to
learn
how
to
how
to
design
apis
and
design
things
well
inside
of
rust.
A
But
I
do
want
to
point
out
that
in
the
cloud
software
space
this
is
the
part
that
is
the
most
rough
for
people
and
honestly,
it
really
is
impressive.
What
the
core
team
and
run
times
like
tokyo
have
done
within
the
constraints
and
of
rust,
and
you
really
can't
complain
when
your
concurrent
code
is
guaranteed
by
the
compiler
to
be
completely
safe
and
correct.
It
saved
us
from
plenty
of
bugs
already,
but
with
that
said,
let's
talk
about
it.
A
A
You
can
make
it
possible
to
run
across
multiple
runtimes,
but
it's
difficult
and
if
anything
in
the
stack
only
runs
on
it
only
runs
on
a
different
runtime
than
the
one
you're
you're
using.
You
have
to
basically
bake
in
some
sort
of
shim
or
thing
to
wrap
it
to
be
able
to
work.
It
keeps
getting
better,
but
it's
just
you
have
to
be
aware
of
it.
Something
to
note
here
is
that
that
the
core
team
has
been
stabilizing
a
lot
of
apis
into
the
standard
library
like
the
stream.
A
One
should
be
landing
soon
and
we
have
the
futures
one
that
allows
standardizing
easier
and
reduces
that
lock-in.
But
just
be
aware
of
it.
The
other
thing
that
we've
noted
is
the
there's
some
ugly
code
and
nested
futures
problems.
So
here
on
the
left
is
something
from
waggy.
You
can,
if
you're,
if
you're
familiar
with
rust,
you'll,
see
why
all
these
clones
and
moves
and
stuff
are
needed
for
memory
safety
purposes.
A
Why
you
need
to
do
it
and
kind
of
like
we
had
to
play
around
with
this
for
an
hour
to
figure
out
which
moves
and
which
clones
and
which
things
we
needed
to
make
it
meet
the
fn,
mute
and
all
the
other
stuff
that's
going
on.
So
it
can
add
to
some
weird
ugly
code
issues,
but
on
the
right
is
something
that's,
probably
the
one
that
can
be
a
little
bit
worse
when
it
comes
with
with
the
ugly
code
and
nested
futures.
A
So
this
code
right
here,
is
actually
what
caused
the
stack
overflow
before
we
boxed
it
properly.
But
right
here
you
we
have
to
like
call
each
individual
thing
fuse
it
box.
It
pass
it
into
a
select
handle
each
of
the
things,
and
this
is
only
part
of
it.
There's
like
another
set
of
tasks
that
have
to
run,
and
then
we
have
to
wait
on
all
of
them.
A
So
we
end
up
with
very
deeply
nested
futures
as
as
these
things
go
along,
which
can
really
like
blow
your
stack
size
and
give
you
some
problems
there
so
just
be
aware
that
that's
there
and
we're
always
around
to
help.
If
you
run
into
that
issue
and
then
last
in
this
section
is
cruft
and
bloat,
and
this
happens
with
async.
What
we've
noticed
is
that
adds
a
lot
of
craft
and
or
bloats
your
code
with
all
the
different
incantations
and
things
you
have
to
do
to
make
it
all
compile.
A
When
you
compare
this
to
other
languages
like
go
in
the
cloud
like
go
in
the
cloud
space,
it's
kind
of
a
hassle
in
comparison
and
it's
something
you
need
to
be
prepared
to
deal
with
so
on
this
left
one.
This
is
us
implementing
async
read
for
an
async
type.
If
I
had
a
dollar
for
every
time
I
had
to
re-implement
async
read
async
write
or
a
stream
for
a
type
when
I
just
end
up
forwarding
that
call
down
the
call
chain.
A
I'd
be
a
rich
man,
but-
and
this
particular
example
kills
me,
because
this
is
already
an
async
type
in
every
way,
but
to
be
able
to
wrap
it
with
the
proper
things
I
had
to
go.
Re-Implement
async
read
on
top
and
as
a
developer,
I
really
don't
want
to
have
to
do
that
and
it's
this
whole
chunk
of
code
that
really,
in
the
end,
is
not
doing
much
for
me
on
the
one
on
the
right.
A
A
You
can
also
see
this
happen
with,
like
your
docs,
when
you
have
an
async
trait,
because
you
have
you
have
to
wrap
it
in
the
async
trait
macro
and
it
creates
a
very,
very
ugly
dock,
so
it
just
adds
craft
and
bloat
that
you're
probably
not
used
to.
I
mean,
like
I
said,
the
benefits
outweigh
these
problems,
but
you
have
to
be
aware
of
it.
A
A
I
personally
don't
think
it's
as
much
of
a
flame
war
as
people
present
it
to
be,
but
there's
some
important,
quick
comparisons
here
that
I
want
to
talk
about
first
off.
What
do
we
miss
from
go?
What
we
miss
from
go
is
an
ease
of
concurrent
task.
Scheduling,
like
I
mentioned
all,
I
have
to
do
say,
go
and
the
function
name
and
it
just
runs
asynchronously
or
concurrently,
not
necessarily
asynchronously,
there's
also
a
batteries
included
standard
library,
including
http
support.
A
I
know
there's
good
arguments
for
having
not
having
like
an
in
like
http
thing
built
into
the
standard
library,
but
it
sure
is
helpful
in
go.
It's
also
easier
to
onboard
new
developers,
it's
much
easier
to
get
started
on
a
go
project
than
a
rust
project.
If
you
haven't
done
either
one
of
them
now.
What
do
we
not
miss
about?
Go
dependency
management,
and
I
don't
want
to
sound
like
a
broken
record.
If
people
have
ever
followed
me
on
twitter
or
read
any
of
my
other
blog
posts
but
go
dependency.
A
A
The
other
thing
is:
if
air
equals
nil
error,
handling
and
rust
is
much
better.
You
still
get.
We
really
like.
The
idea
of
an
error
is
just
a
value
that
you
get
and
go,
but
rust
enforces
it
rather
than
goes
approach
of
just
hoping
that
the
programmer
does
the
right
thing
even
and
then
there's
no
generics
or
even
with
the
new
generics
that
are
coming
in
it's
just
like
I
mentioned
with
the
trade
system.
We
love
it.
It's
much
better
than
anything
go
offers
goes.
A
Governance
model
is
also
being
controlled
completely
by
one
company
and
that's
led
to
various
community
problems
and
projects
at
project
issues.
Rust
has
a
very
open
community
model,
we've
talked
about
the
rust
foundation
and
it's
not
singularly
controlled.
There's
no
collections
or
iterator
functions
and
there's
no
safety,
and
this
isn't
unique
to
go.
But
it's
important
when
we
compare
these
two,
it's
really
easy
to
end
up
with
a
null
pointer
and
go
and,
like
I
said
in
rest,
it's
impossible
without
unsafe.
A
Large
projects
quickly
become
bloated
due
to
that
error,
handling,
lack
of
mapping
and
iteration
tools,
generic
support,
bad
dependency
management.
That's
not
to
say
there
aren't
large
projects
that
do
well
with
go.
We
have
plenty
on
our
team
that
do
it
as
well,
but
the
overall
experience
leaves
a
lot
to
be
desired
so
anyway.
That
is
a
very
quick
overview
of
all
the
different
things
we've
learned
here,
so
I
better
leave
some
good
time
for
questions
or
anything
that
people
want
to.