►
From YouTube: Building Cloud-native applications with Rust - the good, the bad and the ugly - Luca Palmieri
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Building Cloud-native applications with Rust - the good, the bad and the ugly - Luca Palmieri, TrueLayer
Rust has built a reputation as an excellent systems programming language. Yet more than a few companies have chosen to bet on Rust for a completely different type of software: Cloud-native applications. What does Rust have to offer compared to other established languages (e.g. Java, C#, Python, Golang) when it comes to APIs and message consumers? The talk will walk you through TrueLayer's experience. We will cover what convinced us that Rust was a viable option for our latest product (spoiler - not just performance!), the issues and annoyances we experienced along the way as well as what we believe to be some of its intrinsic limitations for the backend development usecase.
A
I've
been
contributing
to
the
russ
community
for
the
past
three
and
a
half
years.
You
might
have
seen
some
of
the
work
I
did
to
get
people
interested
into
the
language
workshops
code
dodges
with
the
last
london
user
group,
or
you
might
have
used
some
of
the
packages.
I
maintain
cargo
chef
for
faster
docker,
builds
or
wiremock
to
test
some
of
your
rest,
api
clients
for
the
past
12
months
or
so.
I've
mostly
been
focused
on
driving
zero
to
production
in
rust,
zero.
A
At
end,
what
drives
most
of
the
conversation
we're
going
to
be
having
today
is
the
work
we've
been
doing
at
true
layer
for
the
past
year
to
later
build
a
new
product
line
called
pay
direct
the
details
of
it.
Don't
matter
necessarily
too
much.
You
can
think
of
pay
direct
as
an
api
which
allows
a
merchant
to
manage
what
looks
like
a
bank
account,
so
their
funds
held
by
two
layer.
A
A
Why
have
you
chosen
bust
and
one
side
of
the
question
we
might
frame
as
a
question
of
novelty
rust,
no
matter
how
ozone
we
believe
it
is.
It's
still
a
young
programming
language
1.0
came
out
shortly
five
years
ago,
more
or
less
compared
to
the
age
of
maturity
of
ecosystems
like
the
jvm,
like
the
clr
like
python
and
typescript
is
still
fairly
young,
so
that
there's
an
inherent
element
of
risk
and
we're
gonna
touch
on
some
of
those
later
on.
A
But
the
other
part,
the
other,
like
intent
behind
the
question,
is
actually
confusion
between
what
people
think
trust
is
and
what
we're
using
russ
for,
and
that's
because
rust
has
made
a
lot
of
his
early
victories
and
a
lot
of
his
most
striking
successes
in
a
different
domain,
not
in
cloud
native
applications
but
in
system
programming,
and
this
is
a
little
scrapbook
that
I
put
together
in
like
five
to
ten
minutes
of
just
high
profile
projects
that
not
so
long
ago.
I've
been
on
the
headlines
for
using
rust.
A
We
often
are
constrained
not
by
how
fast
our
programs
are,
but
on
how
fast
we
can
develop
them.
How
many
mistakes
we
make
along
the
way?
How
fast
can
we
fix
those
and
how
fast,
most
importantly,
can
we
evolve
that
software
over
time?
Speed
of
iteration
is
almost
always
the
biggest
constraint
in
big
cloud
native
deployments,
especially
microservice
architectures.
A
So
why
are
we
using
a
language
which
was
engineered
to
solve
problems
which
are
not
the
problems
of
the
cloud
native
ecosystem?
You
don't
have
to
draw
a
wall
between
different
domains.
Things
which
are
good
for
system
programmer
can
be
equally
interesting
and
equally
beneficial
to
people
working
in
back-end
development.
The
same
applies
to
front-end
and
other
domains
like
game
development,
which
are
usually
seen
as
very
siloed
and
not
communicating
with
one
another
actually
by
fraying.
A
Outside
of
what
is
familiar,
we
can
find
out
that
some
of
the
problems
they
have
are
some
of
the
problems
we
have.
If
you
look
a
little
bit
under
the
surface
and
the
solutions
can
be
reused
and
can
be
the
foundation
to
build
something,
much
more
interesting
for
what
we
want
to
solve
and
that's
pretty
much
going
to
be.
A
The
theme
of
this
whole
talk,
like
you,
have
seen
the
title:
we're
going
to
talk
about
the
good,
the
bad
and
the
ugly
of
using
grass
for
the
club
native
development,
and
this
is
of
course,
based
on
our
own,
very
specific
experience
and
I'm
sure
that
different
people
coming
from
different
backgrounds
trying
to
solve
different
problems
might
have
a
different
take.
But
I
think
it's
important
to
start
to
break
to
an
extent
the
strong
association
that
rust
has
with
system
programming.
A
A
A
Now,
if
this
was
within
a
different
programming
language,
depending
on
what
that
language
was,
this
might
look
slightly
different
in
a
dynamic
language.
You
wouldn't
have
the
types,
so
you
would
infer
that
anything
that
behaves
like
a
token
in
some
not
very
well
defined
way
is
going
to
be
a
valid
input,
and
then
you
would
have
to
write
a
bunch
of
tests
to
make
sure
that
anything
which
is
not
a
valid
input,
fails
in
a
predictable
manner,
for
example,
raising
an
exception,
and
that
is
his
own
problems.
A
Right
is
somebody's
coming
back
to
the
code
base.
Tomorrow
they
don't
know
about
all
those
assumptions
because
they're
not
in
the
run.
They
have
not
loaded
all
the
implicit
knowledge
required
by
the
code
base
and
they
might
make
mistakes
and
if
those
are
not
tested
for,
then
those
mistakes
might
arrive
in
production.
We
don't
like
that.
A
A
It
takes
as
input
a
token
and
you
would
definitely
have
a
gwt
type,
which
has
some
constraints
encoded
inside
the
type
and
it
would
return
some
claims,
but
that
function
might
mutate
the
gwt
token
and
passing
to
it
as
an
input
and
also
it
might
fail.
But
the
signature
doesn't
tell
me
that
it
might
fail.
A
Now,
let's
go
back
to
rust.
Once
again,
I
have
a
scene
keyword
on
the
left.
That
tells
me
this
function
might
do
io,
that's
great
the
token,
not
only
the
gwt,
which
tells
me
something
about
the
structure
of
the
input.
I
also
know
that
I'm
passing
in
a
reference
to
touchywt
and
that's
an
immutable
reference.
A
At
the
end,
I
know
immediately
that
this
function
can
fail,
because
this
function
returns.
A
result
now
result
is
a
way
to
encode
inside
the
type
system
that,
if
things
go
well
I'll
get
a
claims.
But
if
things
go
wrong,
I'll
get
an
error
that
error,
the
verification
error.
I
can
go
and
look
at
the
definition,
and
I
can
see
all
the
different
cases
most
likely
is
going
to
be
an
enum
and
I
can
decide
what
to
do
in
each
of
those
cases.
A
Let's
get
to
the
second
pattern,
which
is
actually
very
important,
but
writing
cloud
native
dress
code
being
able
to
write
state
machines.
Sid
machines
are
everywhere
in
your
programs.
You
have
resources
that
most
likely
have
a
life
cycle
of
sort,
a
user,
a
user
might
sign
up,
they
might
confirm
their
email
and
then
they
might
suspend
their
account
or
close
their
account.
A
A
payment
gets
authorized.
Then
it
gets
booked.
Then
it
gets
submitted.
Then
it
gets
settled
or
it
fails.
They
have
a
finite
number
of
states
which
are
valid
and
they
are
very
clear
business
rules
on
how
to
go
from
state
a
to
state
b,
and
it's
also
clear
that
you
can
go
from
state
a
to
state
c.
This
is
extremely
difficult
to
encode.
If
you're
using
class
hierarchies
like
you,
can
have
an
infinite
number
of
subclasses.
A
Instead,
if
you're
using
rust,
you
can
encode
these
finite
state
machines
using
algebraic
types,
so
using
genomes
in
and
switch
are
able
to
have
values.
So
each
of
the
variants
can
contain
a
payload
is
not
just
a
fancy
way
of
having
an
integer
zero
one.
Two
zero
bending
one
active
to
suspended
each
of
those
is
actually
struct
which
has
fields
can
be
constructed
and
used
and
they're
finite.
So
you
know
if
you
actually
used
and
verified
all
the
possible
parts
every
time
you're
using
a
user.
A
A
You
don't
have
users
yet,
like
your
biggest
focus
at
that
point
in
time
is
getting
more
users,
so
you
focus
on
the
user
creation
part
of
the
user
life
cycle,
so
you
go
to
production
with
pending
an
active
and
all
the
different
parts
of
your
code
basis
know
what
to
do.
If
a
user
is
spending
and
if
a
user
is
active
at
a
certain
point
in
time,
you
realize
the
user
might
want
to
freeze
their
accounts.
You
have
become
successful.
Now
I
have
a
sizable
user
base.
A
Now
this
new
part
of
the
lifecycle
enters
your
domain
model
and
you
need
to
make
sure
that
everywhere
in
your
code
base
when
you're
rendering
a
user,
you
also
are
taking
the
appropriate
action.
If
the
user
is
suspended,
for
example,
they
shouldn't
be
able
to
look
in
and
rust,
helps
you
massively
here,
because
in
ems
being
finite,
so
they're
not
open-ended
class
hierarchy,
that
a
finite
number
of
states
allows
the
compiler
to
actually
do
exhaustive
matching.
A
A
A
As
we
said
before,
the
biggest
constraint
when
doing
enterprise
software
is
how
fast
can
you
iterate
and
in
most
cases
if
your
application
takes
70
milliseconds
instead
of
100
instead
of
150,
doesn't
actually
make
a
massive
difference
to
the
user
in
certain
places
it
does
like.
There
are
bottlenecks
in
the
system
where
you
want
to
be
as
fast
as
possible,
but
there
are
also
plenty
of
parts
where
speed
doesn't
matter.
A
A
Then
the
situation
is
much
more
complicated
and
that
happens
a
lot
if
you're
using
garbage
collective
languages.
But
it's
much
easier
to
reason
about
your
system.
If
everything
you
need
to
look
at
is
the
code,
you
have
written
and
rust
being
able
to
free
memory
in
a
deterministic
fashion,
thanks
to
the
border
checker
and
lifetime
tracking
actually
give
you
that
super
flat
line.
A
A
So
when
we're
building
docker
images
to
release
in
production
on
our
local
machines,
incremental
compilation,
caching,
the
experience
is
fairly
smooth,
but
we
are
experiencing
a
lengthening
of
the
feedback
loop,
which
is
actually
very,
very
important
in
a
company
which
is
write,
code,
commit
merge
to
master
deploy,
observe
the
merge
buster
deploy
step
is
too
long.
I
can't
wait.
15
minutes
to
go
from
code
is
in
my
trunk
to
code
is
running
in
production.
A
Continuous
deployment
is
the
temp
of
your
organization.
If
you
have
an
organization
that
can
only
deploy
once
every
15
minutes,
that
means
that
you
can
make
four
experiments
per
hour
and
you
can
make
with
like
awesome
usage
of
your
time,
which
doesn't
happen.
32
experiments
per
day
in
reality,
probably
there's
something
like
20,
because
I
put
something
in
ci,
then
I
do
something
else.
I
forget
waste
a
bunch
of
minutes,
then
I
go
back
and
so
on
and
so
forth.
A
If
I
can
deploy
every
two
minutes,
I
can
make
the
same
number
of
experiments
within
a
single
hour
and
within
a
day
I
can
iterate
on
so
many
different
configurations
that
actually
I
can
convert
to
what
I
need
much
faster.
This
is
probably
the
most
threatening
aspect
of
the
rust
programming
language
today
when
it
comes
to
adoption
within
the
cloud
native
ecosystem.
A
Therefore,
the
ecosystem
is
moving
like
there's
a
bit
of
churn.
Libraries
are
still
evolving
and
that
might
create
a
little
bit
of
additional
work.
The
other
side
of
it
is
that
a
lot
of
libraries
do
not
exist.
As
of
today,
I'm
talking
about
libraries
to
interact
with
big
vendors.
You
want
to
use
aws.
That
is
risotto
great.
You
want
to
use
gcp.
A
Well,
you
might
have
to
write
a
bunch
of
stuff
on
your
own.
You
want
to
use
volt
same
story,
so
you
cannot
consider,
as
you
might
do,
for
example,
in
python
or
in
node
the
open
source
ecosystem
as
a
vendor.
You
are
shopping
from
once.
You
use
a
package
in
rust,
which
is
open
source.
You
need
to
take
into
account
that
you
might
have
to
devote
a
percentage
of
your
development
time
to
actually
go
and
contribute
to
that
library.
It
may
be
that
the
documentation
is
missing
a
bit.
A
It
might
be
that
there
is
an
unusual
code
path
that
you
are
exercising,
which
is
not
as
well
tested
factor
that
in
like
go
inside
in
the
ecosystem,
with
your
eyes
wide
open,
it
happened
to
us
as
well
like
over
a
year.
We
contributed,
I
think,
almost
10
different
patches
to
fairly
well
known
projects,
so
we're
not
talking
projects
with
one
or
two
stars
so
be
ready
for
doing
your
part
in
pushing
the
ecosystem
forward.
A
Rus
does
not
ship
on
a
sync
executor
inside
the
standard
library,
rust
shapes
the
future
trait
so
shapes
the
interface
on
what
doing
an
asynchronous
task
looks
like,
but
it
pushes
the
actual
logic
to
orchestrate
those
asynchronous
tasks
into
libraries.
At
the
moment
we
have
tokyo
on
one
side,
the
oldest
executor.
Then
we
have
a
institute
now
we're
bastian
and
a
bunch
of
others
with
specialized
use
cases,
and
it's
not
easy
to
interoperate.
A
Third,
intermediate
learning
resources:
rust
is
amazing
when
it
comes
to
getting
beginners
into
the
language
you
have
the
last
book.
You
have
programming
with
trust.
You
have
trust
in
action.
You
have
awesome
video
series
on
youtube
of
different
kinds
and
levels,
but
when
you
want
to
do
cloud
native
development,
there's
a
lot
more,
that
is
not
in
those
resources,
as
seeing
kuwait,
for
example,
is
often
not
contemplated.
A
What
libraries
to
use
now
discussed
how
to
stitch
them
together,
not
really
discussed
part
of
this-
is
why
I
brought
zero
to
production.
Bust
is
like
I
don't
plan
to
have
this
as
an
official
resource.
This
is,
as
the
title
says,
an
opinionated
way
of
getting
something
that
works
or
putting
a
bunch
of
tools
inside
the
box
and
getting
you
something
that
you
can
use.
We
trust
to
make
this
kind
of
programs,
but
I'd
like
to
see
more,
like
I
like,
to
see
more
resources
with
different
angles:
videos
books
that
take
a
different
approach.
A
People
need
to
have
the
possibility
to
choose
how
to
approach
the
ecosystem,
because
everybody
learns
differently
and
there's
a
void.
A
massive
void
here
that
needs
to
be
filled
in,
and
that
was
the
last
item
in
the
list
of
ugly
things
that
they're
seeing
rust
for
cloud
native
today
thanks
a
lot
for
tuning
in.
I
hope
this
was
a
useful
presentation
and
shared
an
experience
that
you
can
learn
from.
If
you
have
any
questions,
I'm
happy
to
take
them
now.