►
Description
Is Rust a great language for building Kubernetes ecosystem?
When it comes to building tools for the Kubernetes ecosystem, your first thought would be Golang, I'm here to explore if Rust is a better alternative, especially for in-cluster tooling that needs to have minimal overhead and for WebAssembly workloads. Rust is also great for building Kubernetes tooling like CLI apps and so on.
I'll be also sharing and showcasing KDash - a Kubernetes CLI dashboard that I built using Rust and we will look at the Kubernetes-Rust ecosystem that is rapidly evolving and why you should consider it
- Rust vs Golang for k8s use cases
- Advantages of Rust over Golang
- Ideal Kubernetes use cases for Rust (WASI, tools, proxies)
- Real-life use case and example (KDash)
- State of the Rust ecosystem for DevOps and K8s
About Deepu K Sasidharan
Deepu K Sasidharan is a Software Engineer by passion and profession. He is a Java Champion working as a Senior Developer Advocate at Okta. He is the co-lead of JHipster and the creator of KDash and JDL Studio. He is a polyglot programmer working with Java, JavaScript, Go, Rust, and so on. He is also a cloud technology advocate and an open-source software aficionado. He has authored books on Full-stack development and frequently writes about Java, JavaScript, Go, Rust, DevOps, Kubernetes, Linux, and so on, on his blog.
Deepu on Twitter: https://twitter.com/deepu105
Rust Linz on Twitter: https://twitter.com/rustlinz
Slides: https://speakerdeck.com/deepu105/is-rust-a-great-language-for-building-kubernetes-ecosystem
A
Awesome
so
let's
get
started
yeah,
as
you
all
probably
already
know.
So
today,
I'm
going
to
talk
about
some
rust
in
the
community
space
right.
I
do
want
to
give
out
a
disclaimer,
I'm
not
a
rust
expert,
because
I
see
nick
you
know
coming
up
after
me.
Who
is
the
who
is
probably
a
rest
expert,
I'm
more
of
an
intermediate
arrest
person
so.
A
B
A
I'm
also
a
java
champion
quite
recent,
so
it's
it's
also
a
bit
weird
that
I'm
here
talking
about
trust,
but
that's
all
fine.
I
also
created
a
nifty
dashboard
called
k
dash
for
kubernetes
among
many
other
open
source
stuff.
I'm
an
open
source
aficionado
have
been
doing
open
source
for
I
think
yeah,
seven,
eight
years
now,
I'm
also
polyglot
developer.
I
work
on
on
java.
A
Javascript
typescript
go
rust
among
others,
so
I
I
don't
discriminate
between
languages,
not
not
much
so
I
work
at
octa
as
a
developer
advocate
with
the
focus
on
devops.
I
also
frequently
write
on
my
personal
blog
about
tech
topics,
so
you
can
find
it
on
debut.tech
if
you're
interested
in
my
content,
you
can
also
follow
me
on
twitter.
A
If
you
want
to
get
updates
on
content,
I
publish
I
also
written
some
books,
mostly
around
jhipster,
so
yeah,
and
you
can
find
most
of
my
social
handles
on
the
screen.
So,
let's
get
started
so
before
we
go
into.
You
know
the
the
the
topics
of
how
russ
fits
into
devops
world
and
how
it
is
better
than
go
and
all
those
things
I
want
you
to
introduce.
You
to
something
I
built,
so
it's
called
k
dash.
So
it's
a
simple,
so
it's
a
simple
terminal:
dashboard
for
communities.
A
A
It's
a
cli
dashboard
basically
reads
out
from
your
kubernetes
configuration
and
it
shows
you
a
cube,
ctl
kind
of
view,
but
more
interactive.
So
there
is
full
keyboard
navigation.
You
know
where
you
can
go
to
stuff.
You
can
switch
between
contacts.
You
have
a
really
nice
utilization
view
that
shows
your
playstation
for
your
entire
cluster,
which
is
quite
handy.
In
my
opinion.
A
A
A
A
I
know
the
the
the
cli
tool
k
dash
and
what's
my
first
serious
arrest
project,
so
I
have
been
you
know
going
through
rust,
stuff
learning
here
and
there
a
bit
of
rust
trying
you
know
small
things.
I
never
had
an
opportunity
to
build
something
holistic,
you
know
so
I
I
was
pondering
over
what
to
build
and
I
I
finalized
on
building
a
k
dash
and
I
I
built
it
in
rust
and
I
learned
a
lot
of
rust
while
building
k
dash.
I.
A
Fun
experience
I
I
never
had
so
much
fun
in
the
recent
few
years,
working
on
anything
as
much
as
I
did
on
k
dash,
and
I
think
most
of
the
credit
goes
to
rust,
being
an
awesome
language
and
the
developer
experience
of
working
with
trust.
Being
so
awesome
that
I
was
I
was
like
addicted
to
working
on
that
would
I
would
wake
up
early
mornings,
sometimes
with
some
idea
on
my
head
and
I'll
start
coding.
A
B
A
A
So
when
I
started
learning
rust,
I
I
wanted
something
build
something
which
is
more
than
hello
worlds
and
to-do
apps,
and
I
wanted
something
serious
something
that
has
a
good
architecture.
Something
which
will
have
a
lot
of
challenges,
so
I
decided
to
also
build
something
that
could
be
useful
right
so
and
since
I'm
on
the
canine
sorry
community
space
a
lot,
I
thought
it
would
be
nice
to
build
something
in
in
the
community
space
so
that
I
can
also
kind
of
poc
the
idea
about
using
rust
for
community
stores.
A
So
I
was
also
using
kns
and
there
were
some
things
that
you
know
was
some
some
things
I
preferred
to
be
better
and
and
in
terms
of
user
experience
in
terms
of
speed
and
stuff.
So
I
thought
it
could
be
a
nice
idea
to
build
something
similar
since
there
weren't
many
other
projects.
You
know
similar,
especially
there
was
nothing
in
the
rest
space.
A
So
I
decided
to
go
ahead
with
that.
So
the
the
focus
when
I
was
building
k
dash
was
definitely
ux
and
navigation.
That
was
the
primary
goal.
Of
course,
the
the
speed
and
everything
just
was
add-on
provided
by
rust
right,
so
that
that
was
not
the
focus,
so
simpler
user
experience
and
navigation
was
the
focus.
But
of
course,
in
the
end,
when
I
finished
without
doing
anything
or
without
spending
any
effort,
I
did
also
get
a
way
better.
A
Efficiency
like
k,
uses
much
less
resources,
then
cubes
even
cube
ctl,
of
course,
then
much
less
resources
than
kns,
but
also
then
cube
ctl.
Even
if
you're
running
cube,
ctl
commands
on
watch,
it
will
still
use
way
more
resources
than
k
dash.
Of
course,
it's
not
like
too
meaningful
when
we
talk
about
you
know
in
in
megabytes,
but
still
it
uses
way
more
resources
than
k
dash.
So
that's
all
from
rust.
A
You
know
for
free,
and
so
the
the
obvious
question
I
get
after
when
I
talk
about
this,
the
obvious
question
I
always
get
is
why
rust
and
why
not
go
land
because
most
of
the
stuff
in
the
communities
world
is
built
using
go
right
and
even
kubernetes
itself
is
built
on
go
and
most
of
the
tooling.
The
infrastructure
around
kubernetes
is
all
built
in
co,
so
and-
and
it
has
go,
has
a
lot
of
libraries
to
help
build
communities,
ecosystem
tools
and
stuff.
So
why
not
go?
Why
why
why
russ?
A
What
what
advantages?
Do
you
get
right?
That's
a
valid
question,
and
since
most
of
the
community
space
is
built
with
go
honestly,
go
is
an
excellent
language
for
these
purposes
right
and
there
is
not
a
lot
of
solid
reasons
to
choose
rust
or
go
for
a
user-based
space
project
like
k
that
that's
a
different
thing,
but
there
are
communities
use
cases
where
rusty
is
a
way
better
choice
than
gold.
Some
ideal
examples
would
be
side.
A
Car
applications
like
a
proxy,
you
know
similar
to
linker
d
or
envoy
lingard
proxy
is
already
returned
in
rust,
so
so
proxies
side
cars
side.
Cars
are
like
applications
that
would
live
alongside
your
port.
You
know
in
in
your
in
in
your
in
your
cluster
and
they
have
to
be
lightweight.
They
have
to
be
fast.
You
know
they.
They
cannot
have
a
lot
of
overhead
so
so
that
they
don't
slow
down
your
actual
applications.
So
side
cars
are
ideal.
A
A
So
rust
should
be
ideal
for
these
kind
of
projects
in
cluster
tools,
like
log
aggregation
monitoring,
ebpf
building,
kubernetes
operators,
web
assembly
workloads.
These
are
also
use
cases
where
rest
would
be
a
much
better
choice
than
go
when
it
comes
to
building
the
kubernetes
ecosystem
right,
but
for
use
of
space
projects
like
k,
dash,
for
example,
it
doesn't
make
that
much
of
a
difference.
You
can
build
it
in
go
or
rust
in
the
end
more
or
less
you
know,
there
won't
be
a
huge
difference.
A
A
A
So
so,
like,
like
you
know
overall,
I
I
do
believe
that
rusty
is
an
ideal
candidate
to
build
out
the
community's
ecosystem
along
with
go
of
course,
because
go
still
has
value
and
adding
rust
into
the
mix
will
only
make
the
ecosystem
better.
We
would
have
a
lot
more,
I
mean
much
more
safer
applications,
faster
applications
and,
and
so
on.
A
A
So,
in
my
opinion,
you
know
when,
when
we
talked
about
the
ideal
use
cases
right
and
even
for
the
use
of
space,
if
we
have
to
you
know
nitpick,
then
definitely
there
are
a
lot
of
advantages
that
that
rust
offers
right
again,
I'm
not
going
to
go
into
details
because
I
believe
most
of
the
people
tuning
in
are
familiar
with
trust
and
they
know
what
trustees
and
everything.
So
I'm
just
going
to
go
to
few
things
that
I
consider
quite
important.
A
Of
course,
safety
would
be
the
number
one
benefit
right
of
using
rust
over
go
and
so
memory.
Safety
is
currently
like
one
of
the
biggest
issues
that
we
have
right
memory.
Safety
related
issues
are
like
cost
of
majority
of
security
cvs
we
encounter
undefined
behavior
can
be
abused
by
a
hacker
to
take
control
of
a
program
or
to
leak
privileged
information
right
in
memory
safe
languages.
A
If
you
try
to
access
an
rl
element
out
of
its
bomb,
you
just
crash
the
program
with
a
panic
or
error
which
is
predictable
behavior,
whereas
in
in
memory
unsafe
languages
like
cc,
plus
which
we
are
still
using
to
build,
you
know
like
side,
cars
and
proxies
like
like
envoy
proxy,
for
example
like
still
being
used.
So
there
is
a
lot
of
chances
of
introducing
security,
vulnerabilities
right
and
and
these
these
stats,
these
stats
kind
of.
A
If
you,
if
you
put
this
together,
it's
like
it's
like
memory,
safety
issues
are
causing
like
more
than
70
percentage
of
cvs.
We
encounter
across
platforms
across
products.
So
why
do
we
still?
You
know?
Why
do
we
still
fall
for
that?
And
why
do
we
still
use
memory
unsafe
languages
to
build
tools
like
you
know,
proxies
and
stuff
like
that?
A
So
in
my
opinion,
rust
can
be
a
boon
in
in
that
area,
especially
to
build
out
such
you
know
what
you
call
like
sensitive
applications
or
like
such
integral
applications,
like
proxies,
you
know,
especially
for
service
measures
and
so
on.
So,
for
me,
safety
is
like
the
number
one
advantage
of
rust
or
go
so
memory
safety.
Of
course,
threat.
A
A
Recently,
the
microsoft
team
found
some
issues
with
helm,
which
is
written
in
go
race,
condition,
issues
which
would
never
happen
in
trust
right.
So
these
are
the
safety
guarantees
that
russ
gives
us,
which
would
be
very
helpful
for
us.
So
helm
is
a
user
space
project,
so
even
for
that
rust
still
would
make
it
better,
though.
Ideally
it
may
not
make
it
way
better
like
in
terms
of
a
proxy
or
something,
but
it
still
would
make
it
better.
A
So
the
safety
thing
and
my
most
favorite
thing
about
trust
hands
down
is
like
the
the
zero
cost.
Abstraction
features
right,
so
I'm
I
assume
most
of
you
already
know
about
this,
but
just
to
summarize
so
in
rust.
One
thing
I
loved
when,
when
I
was
working
on
rust
and
when
I
was
writing
the
project
k
dash
and
rust
was-
I
didn't-
have
to
constantly
worry
about
picking
the
right
approach.
For
example,
I
didn't
have
to
worry
about
hey.
Should
I
do
this
in
function?
A
Should
I
follow
functional
programming
approach,
or
should
I
do
imperative
programming?
Should
I
do
object
oriented?
I
didn't
have
to
worry
about
any
of
this
because
it
didn't
matter
in
the
end,
the
style
of
my
this
in
the
style
in
which
I
I
programmed
didn't
matter,
because
the
zero
cost
abstractions
ensured
that,
regardless
of
how
I
write
or
wrote
my
program,
the
end
result
was
always
as
performant
as
it.
It
could
be
right,
which
is
not
the
case
in
many
other
languages
like
most
of
the
languages.
A
I
I
think,
except
for
c
plus,
I
think
no
other
language
offers
zero
cost
abstractions
like
this
in
in
this
way.
So
I
think
that
is
that
was
quite
freeing
in.
In
my
experience.
You
know
it
took
away
a
lot
of
the
the
the
the
the
thinking
process
that
you
would
normally
have
to
do.
So
I
I
didn't
have
to
worry
about
that.
I
could
just
have
fun
in
coding
like
I
could.
I
could
go
like
ahead
and
like
do
whatever.
A
A
You
know
any
performance
impact
or
I
could
I
could
create
layers
and
layers
of
abstractions
and
I
didn't
have
to
worry
about
these
creating
performance
impact.
So
that
was
like
one
of
the
greatest
thing
that
I
experienced
and
I
liked
about
trust,
which
I
think
is
way
under
what
you
call
undervalued
feature.
I
would
say,
for
example,
right
like
so
I'm
I'm
a
long-term
java
programmer
as
well.
So
you
can
see
on
the
left
is
a
java
program
on
on
on
the
right
is
a
rust
program.
A
Both
are
doing
quite
quite
similar,
stuff
right.
So
it's
doing
factorial
using
three
approaches.
So
there's
a
factorial
using
traditional
for
loops
like
the
imperative
way.
There
is
a
recursive
way
and
there
is
a
factorial
using
the
inbuilt
functional
apis.
So
in
in
case
of
java,
it's
the
stream
api
and
for
rust,
it's
the
inbuilt,
inbuilt
functional
apis
like
fold
in
in
this
particular
case,
and
if
you
look
at
the
benchmark,
so
I
ran
benchmarks
for
both
for
the
the
java
benchmark.
A
You
can
see
the
factorial
with
loops
performs
the
best
it's
obviou
or
very
obvious
right,
because
imperative
code
in
most
of
the
cases
imperative
code
will
have
better
performance
because
there
are
less
indirections
and
there
are
less
abstractions
right
and
then
the
recursive
one
was
twice.
I
mean
like
like
twice
the
most,
if
that's
the
right
way
to
put
it
and
then
finally,
the
inbuilt
functional
approach
was
like,
like
a
slightly
bit
more
slower.
A
So
this
is
to
be
expected,
whereas
in
the
rest
version
the
performance
for
the
loop
and
recursion
recursive
versions
were
almost
identical
and
the
performance
for
the
inbuilt
performance
using
the
inbuilt
you
know,
functional
abstractions
was
even
higher
and,
and
I
looked
into,
I
was
surprised
at
first
then
I
I
did
some
digging
around
and
I
found
that.
Okay,
the
inbuilt
a
lot
of
the
inbuilt
abstractions
also
have
additional.
You
know,
bound
checks
and
these
things
that
that
improves
performance.
A
Of
course,
in
my
my
you
know
naive,
you
know
sample
implementations.
I
didn't
do
any
of
those,
that's
why
there
is
additional.
You
know
performance,
but
but
the
take
away
is
that
because
of
zero
cost
obstruction,
the
style
is
not
gonna
matter,
so
you
can
go
full
functional.
You
can
write
imperative
objector
into
whatever
it
doesn't
matter.
It's
going
to
give
you
the
same
performance
once
it's
compiled
and
you
don't
have
to
worry
about
it.
B
A
My
opinion
so
yeah,
of
course,
there
are
a
lot
more
other
other
things
that
I
like
about.
Russ,
for
example,
the
tooling
and
community,
is
one
of
the
best
that
I
have
encountered
like.
I
have
worked
with
many
languages
and
so
far
I
I
don't
think
I
have
come
across
any
other
language
which
has
such
nice
compiler
such
user-friendly,
tooling,
like
cargo
and
the
entire
ecosystem,
and
also
the
community
such
helpful,
and
you
know,
vibrant
community.
So
that's
definitely
another
plus
point
for
us.
A
The
tooling
is
way
better
than
go
in.
In
my
experience,
I
have
done
some
serious
development
using
go
back
in
the
days
and
huge
projects
with
like
a
medium
sized
team
and
the
developer.
Experience
of
using
go
doesn't
even
come
close
to
the
developer
experience
of
using
rust
so
that
that's
also
another
plus
I
I
don't
want
to
turn
this
into
a
go
was
trusting
it.
So,
let's
move
on
so
of
course,
so
you
know
high
level
languages
was
lower
level
languages.
A
A
If
you
take
java,
you
can
take
safety,
and
maybe
you
know
maybe
speed
a
little
bit
of
speed,
but
no
abstractions,
probably,
and
if
you
take
go,
then
it's
the
same
right
so
that
that
that
trade-off
is
not
present
with
trust,
because
you
get
safety,
speed
and
abstraction.
You
get
all
three
and
you
don't
have
to
choose.
So
that's
where
I
think
rust
stands
out
among
other
languages.
A
Of
course,
it
didn't
fare
that
well
in
the
memory
usage
which
was
contested
because
in
real
world
experiences,
even
in
my
personal
experience,
the
memory
usage
of
rust
was,
I
anecdotal
evidence,
of
course,
but
I
didn't
have
a
a
a
case
where
rust
was
using
more
memory
than
go,
for
example
right.
So
this
could
this
could
this
could
be
based
on
the
implementations
they
chose
and,
of
course
there
was.
A
I
think
there
was
some
difference
of
being
in
the
community
about
how
the
implementations
were
done,
but
but
it's
still
good
to
know
that
rusty
is
quite
energy
efficient,
which
makes
sense,
because
it's
quite
fast
so
in
my
opinion,
people
won't
appreciate
rust
unless
they
spend
few
weeks
building
something
in
it.
So
the
initial
steep
learning
curve
is
there
it's
a
thing,
so
it
could
be
frustrating
or
challenging
depending
on
how
you
see
it.
A
For
me
it
was
challenging,
but
I
can
also
see
that
it
could
be
frustrating
for
someone
if
they
are
just
trying
to
get
something
done
right,
but
once
past
that
point,
maybe
a
few
weeks
in,
I
think
it's
hard
not
to
love
rust
right.
It's
like
a
toddler
with
super
power
right
and
and
honestly
writing
less
code
is
much
more
pleasant
experience
overall
like
compared
to
many
other
languages.
So
I
really
like
this
quote
from
tech
republic,
which
I
think
is
really
is.
A
I
would
say
so:
let's
get
into
some
use
cases
and
the
like,
like
the
ecosystem,
that
we
have
in
terms
of
using
rust
with
kubernetes
right.
So
we
thought
we
spoke
about
web
assembly.
I
didn't
want
to
go
into
too
much
details
of
it
assembly
because
I
I
believe
there
was
some
talks
around
web
assembly
and
trust
in
the
past
in
the
meetup.
A
So
I
don't
want
to
go
too
deep,
but
the
web
assembly
system,
interface
or
wassi
makes
it
possible
to
run
vassam
workloads
in
kubernetes,
and
it's
still
quite
new
and
has
a
lot
of
rough
edges.
I
wrote
a
blog
post
about
it.
You
can
find
the
link
on
the
bottom
of
the
on
the
of
this
slide.
It's
it's
quite
rough.
It's
not
product.
A
Definitely
not
production
ready,
but
it
could
be
the
future
of
a
containerless
kubernetes,
because
web
assembly
would
make
docker
containers
obsolete
because
they
technically
do
they
both
do
the
same
thing,
but
web
assembly
containers
or
assembly
oc
oci
images.
You
cannot
call
them.
Containers
like
web
assembly
right,
it's
its
own
format,
so
assembly
gives
the
same
advantages
as
containers
and
but
gives
more
sandboxing,
more
security
and
and
stuff
like
that.
So
it's
a
it's.
A
It's
like
a
better
alternative
to
container
so
this
this,
if,
if
this
technology
gets
adopted,
gets
a
good
ecosystem
around,
there
are
still
some
issues
like
networking
is
a
mess
currently,
so
those
needs
to
be
taken
care
of.
So
once
all
that
happens,
I
think
web
assembly
on
kubernetes
has
a
bright
future
and
can
make
you
know,
containers
obsolete,
of
course,
not
talking
about
like
in
the
short
term,
but
in
the
long
term,
because
migrating
from
the
current
world
of
docker
is
not
going
to
have
an
open
happen
overnight
right.
A
So
that's
going
to
take
some
time,
but
when
we
talk
about
web
assembly
and
was
on
workloads
and
kubernetes,
of
course
you
can
build
a
web
assembly
by
navasa
binaries
using
any
supported
language.
You
don't
have
to
do
it
in
trust,
but
rust
has
one
of
the
best,
tooling
and
ecosystem
for
us
so
and-
and
that
makes
it
an
ideal
language
to
build
bossy
workloads
for
communities
as
well.
A
So,
for
example,
vassam
time
is
a
jit
style,
standalone
runtime.
This
is
what
makes
it
possible
to
run
web
assembly
on
kubernetes,
for
example,
because
web
assembly
was
originally
meant
to
be
meant
for
the
web.
It
was
a
web,
it
was
meant
for
web
band
was
meant
to
run
in
browsers,
so
in
order
to
run
it
outside
of
a
browser,
you
need
a
runtime
and
vason.
Time
is
one
of
that.
A
A
Times
there
is
a
vasa
med,
which
is
a
runtime
focused
on
micro
services.
It's
it's
more
commercially
oriented.
It's
focused
on
micro
services.
It
is
built
using
c
c
c,
plus
plus,
but
also
offers
rust
binding
so
that
you
can
directly.
You
know,
build
against
that.
Like
applications
against
that
in
trust
us
so,
and
there
is.
Finally,
there
is
awesome
cloud
which
is
focused
on
distributed
actors
rather
than
workloads,
which
is
also
returning
russ.
A
So
all
all
these
three
runtimes
times
will
let
you
work
with
rust
and
it
makes
e,
I
mean
they
all
provide
rust
bindings.
I
mean
the
two
of
them
are
return
interest.
That
means
you
can
directly
use
them
in
your
rust
project.
Wasa
meh
provides
trust
binding.
So
you
can
also
use
that
in
your
res
project,
so
it
makes
it
easy
to
build
stuff
for
these
kind
of
these
run
types.
And
finally,
there
is
also
crosslit,
which
is
based
on
vason
time.
A
It's
a
cube,
led
written
in
rust
and
can
run
oca
savasan
binaries
in
the
oca
format.
So
awesome
binaries
can
be
built
as
a
oci
images
open
container
images,
though
they
are
not
containers,
but
you
can
still
build
them
as
oci
images
and
you
can
run
them
using
chrysler
and
the
the
blog
that
I
have
linked
down
here.
A
So
the
next
use
case
would
be
in
cluster
twos,
right
proxy
side
car
service
measure.
We
we
briefly
spoke
about
this.
Of
course
rust
is
going
to
make
it
a
much
nicer.
In
terms
of
of
course,
it's
going
to
be
fast,
there's
going
to
be
some
better
safety
than
using
c
plus
bus
and
it's
going
to
be
efficient
right,
and
so
it
makes
it
ideal
for
building
side
cars,
proxies
service,
mesh
infrastructure
stuff,
like
that,
so
linker.
A
A
very
popular
proxy,
so
I
think
linker,
d
and
envoy
are
the
two
most
popular
proxies
in
the
communities.
World
and
envoy
is
returning
c
plus
and
linger
d
is
written
in
rust,
so
lingard
was
originally
written
in,
go
which
was
later
migrated
to
rust,
which
which
makes
sense,
then
another
use
case
would
be
k
it
as
operators
right
so
rus,
asynchronous
programming
model
is
a
perfect
match
for
building
high
performance
or
high
throughput
or
highly
parallel
operators.
A
So
you
can
have
operators
which
are
you
know,
doing
parallel
processing
without
having
to
worry
about
race
conditions
and
stuff.
You
can
build
high
performance
operators,
so
this
is
all
this
is
another
use
case
area
where
rust
would
shine
better
than
go
in
terms
of
performance
and
in
terms
of
ease
of
use,
it's
going
to
be
light
on
resource
usage
and
footprint,
and
also
it's
going
to
be
way
less
code
right.
A
Writing
an
operator
in
rust
and
go
is
going
to
be
a
different
experience,
because
with
rust
you
can
once
you
have
some
basic,
so
macros
or
something,
then
you
know,
building
out
new
operators
would
be
like
quite
straightforward
and
very
little
code
compared
to
how
you
do
it
in
go.
For
example,
another
use
case
would
be
log
aggregation,
monitoring,
ebpf
and
these
kind
of
things,
so,
especially
in
a
kubernetes
container,
where
you
want
your
resource
usages
to
be
kept
minimum
so
that
your
applications
can
have
more
resources.
A
It
makes
sense
to
build.
You
know
crawlers
or
log
aggregation
agents
and
these
kind
of
things
in
trust
so
that
they
take
very
little
footprint.
They
don't
impact
too
much
in
terms
of
performance
and
and-
and
you
know,
they're
quite
fast
as
well
right.
Another
area
would
be
ebpf,
which
is
the
the
current
kind
of
the
ideal
way
to
collect
logs
or
or
for
observability
right
in
the
linux
kernels.
A
So
there
is
already
a
solution
called
red
bpf,
which
is
a
tool
chain
to
work
with
ebpf,
which
could
mean
that
in
your
kubernetes
setup
you
could
use
this
to
build.
I
don't
know
law,
observability
solutions,
monitoring
solutions,
logging
solutions,
security
solutions
and
so
on.
So
these
are
all
the
use
case
that
I'm
kind
of
envisioning
for
rest
in
the
community
space
and,
of
course,
there
is
finally
use
of
space
tools.
A
I
won't
say
this
is
the
most
important
aspect,
because
in
cluster
tools
and
web
assembly
would
be
the
most
important
and
is
is
use
cases
where
rust
can
actually
add
a
lot
more
value
than
the
current
solutions
out
there
in
the
user
space
tools.
Of
course,
you
can
build
stuff
using
rust.
It's
not
going
to
have
too
much
of
an
impact
compared
to
building
in
go
or
something,
but
it's
still
possible.
I
mean
I
built
k
dash
using
it.
A
There
are
a
few
others
which
are
quite
nice,
like
there
is
qb,
which
is
a
kubernetes
contact,
switching
and
prop
modification
utility
for
the
for
your
shell.
There
is
cube,
ctl
view
allocations,
which
is
the
library
that
I
have
used
in
k
dash
as
well
to
see
your
kubernetes
usage,
metrics
and
stuff
like
that
and
then
finally,
there
is
click
which
is
a
command
line,
interactive
controller
for
communities
more.
A
Like
a
rebel
for
communities,
so
these
are-
and
there
are
a
lot
of
other
another
other
other
smaller
use
of
space
tools
and,
of
course
anything
that
you
can
build
and
go.
You
can
also
technically
build
in
rust,
so
for
a
rust
programmer.
You
know
it
shouldn't.
Stop
you
from
building
kubernetes
tools,
just
because
you
you
don't
want
to
write
it
and
go
doesn't
mean
that
you
don't
have
you
don't
have
other
options.
You
cannot
still
write
it
in
trust
and,
of
course,
for
this
we
would
need
a
library
ecosystem.
A
There
are
quite
some,
I
won't
say
it
is
as
good
as
go
in
terms
of
you
know
the
diversity
of
libraries,
but
most
of
the
important
ones
are
already
there,
for
example,
q
bars,
which
is
the
kubernetes
client
for
us.
So
I
used
that
in
k
dash
k
dash.
So
this
is
equivalent
to
the
go.
Kubernetes
go
client
in
terms
of
features
and
everything.
It
doesn't
have
some
bells
and
whistles,
but
since
it
is
written
in
rust,
we
have
really
nice
generics
and
macros
and
stuff
like
that.
A
So
the
library
also
provides
some
some
generics
generic
traits
and
stuff
which
you
can
easily
extend
to.
You
know,
bridge
whatever
gap
you
will
find.
For
example,
for
example,
when
I
used
the
q
bars
library,
the
metrics
api
didn't
have
any
implementation
in
this,
whereas
the
the
go
version
has
a
metric
api
implementation,
and
so
I
was
looking
I
was
like
like
thinking.
Oh,
I
don't
have
this,
or
should
I
use
another
library?
Should
I
use
my
own?
Should
I
just
build
my
own?
A
You
know
bridge
between
that,
but
then
then
I
went
to
the
cubara's.
You
know
issue
list
and
opened
an
issue
and
yeah.
Then
there
was
a
really
nice
suggestion.
Hey
you
have
this
generic
trade
just
implement
this
and
you're
done,
and
that's
it
like
five
lines
of
code-
and
I
was
done
so
even
even
to
implement
a
feature
that
was
not
there.
It
only
took
like
five
lines
of
code
like
using
that
generic
and
providing
some
configuration
and
that
that
was
done.
A
A
Then
you
have
risotto,
which
is
a
rust
sdk
for
aws
and
of
course
there
is
also
the
official
aws
sdk
first
and
there
is
a
prometheus
parser
to
pass
and
validate
a
prometheus
query
expressions.
Of
course,
there
are
a
lot
more
smaller
libraries.
You
would
find.
Of
course,
you'll
you'll
find
a
lot
more
libraries.
I
just
listed
the
ones
with
a
lot
of
users
or
like
a
lot
of
downloads
and
stuff,
like
that,
a
lot
a
lot
of
smaller
ones,
but
the
the
ecosystem
around
kubernetes
for
rust
is
still
evolving.
A
I
won't
say
it
is
unusable
at
this
moment.
It
is
still
I
I
have
seen
a
lot
of
production
examples
of
this
being
these
libraries
being
used,
so
it
is
as
good
as
I
won't
say,
it
is
as
good
as
the
go
ecosystem,
but
it
is
getting
there.
I
think
in
few
more
years.
I
think
this
would
be
as
good
as
the
go
ecosystem,
so
this
would
be
ideal
time
to
actually
start
considering
rust
for
kubernetes
based
use
case.
A
A
A
No
I
this
was
like
some.
I
had
some
optional
slides.
I
wanted
to
make
sure
if
I
have
time
to
go
through
them,
so
I
think
I
have
a
few
more
minutes
to
go
through
so
that
that's
fine,
so
yeah.
I
did
want
to
touch
up
a
little
bit
on
the
k,
dash
architecture
just
to
show
it's
all.
It
wasn't
all
hunky
dory,
so
I
just
wanted
to
go
through
a
few
things.
A
I
learned
on
the
way
so
so
k
dash
yeah,
so
I
used
of
course
I
used
a
bunch
of
libraries,
so
I
did
want
to
mention
them.
So
t-u-I-r-s
was
like
a
one
of
the
best
ui
libraries
that
I
have
worked
with
it's
so
nice,
so
it
helped
me
build
a
rich
ui
on
the
terminal,
so
so
that
was
really
good.
So
it's
like
you
know
what
are
those
the
the
the
the.
B
A
I
forgot
the
name
for
it.
What
are
they
okay
never
mind?
So
then
there
is
cross
term,
which
is
a
terminal
manipulation
library
which
is
used
by
turos.
Turs
supports
few
other
terminal,
manipulation,
libraries
as
well.
I
went
with
crosstown
so
that
I
can
add
support
for
both
windows,
linux
and
and
mac.
A
Of
course,
tokyo
tokyo
is
unavoidable
in
any
rus
project.
These
days,
because
k
dash
is
fully
event
driven
and
non-blocking
asynchronous
stuff.
So,
like
yeah
tokyo
was
like
a
obvious
choice
for
that
and,
of
course,
q
bars
with
k.
It
has
open
api,
open,
ssl
and
all
those
stuff
cube,
ctl
view
locations
for
some
metric
stuff,
clap
for
command
line
argument,
password
used
few
of
the
smaller
libraries
like
rust,
clipboard,
surday
for
civilization
and
stuff
and
that
dollars.
So
these
are
the
libraries
I
used
and
data
architecture-wise.
A
A
So
that
there
is,
there
was
nothing
blocking,
and
since
I
was
using
tokyo,
it
was
quite
easy
to
split
everything
into
multiple
threads.
So
there
was
like
one
thread
which
was
just
taking
care
of
rendering
the
ui.
There
was
another
thread
that
was
taking
care
of
network
requests
and
there
was
another
thread
that
was
taking
care
of
parsing
commands
and
like
running,
commands
and
stuff
like
that.
A
So
I
think
there
are
three
or
four
threads
and
there
is
one
data
store
and
they
used
r
plus
mutex
for
a
shared
state,
a
data
store,
so
that
I
mean,
of
course
in
trust.
It
was
so
easy
to
do
this
because
you
didn't
have
to
worry
about
data
races
and
stuff
like
that
and
having
arc
matrix,
a
single
data
store
with
multi
threads,
and
you
know,
event
driven
architecture
made.
B
A
I
would
have
to
pay
so
much
more
attention
into
data
races
and
you
know
not
corrupting
data
from
multiple
threats
and
stuff
like
that
here
didn't
after
a
while,
I
didn't
even
have
to
worry
about
it
and
honestly,
I
forgot
that
you
know
I
was
working
in
a
multi-threaded,
asynchronous
application
and,
of
course,
non-blocking,
ui
and
and
stuff
like
that,
thanks
to
multiple
threads
and
even
driven
io.
So
the
only
bottleneck
I
faced
was
the
network
io
with
the
cube
api
server,
which
is
you
know,
because
the.
A
Is
not
working
in
a
non-blocking
asynchronous
way
right?
That
is
only
bottleneck.
I
still
have
so
I'm
hoping
that
will
improve
on
the
library
side,
and
this
this
part
will
be
better.
It's
not
noticeable,
but
if
you
do
too
many,
if
you
do
too
many
network
requests,
you
can
sometimes
see
see
the
bottleneck.
A
Of
course,
there
were
challenges
like
log
streaming
was
like
the
the
most
challenging
part.
For
me,
it
was
because
the
the
way
log
streaming
was
provided
by
the
underlying
cube
rs
library
didn't
work
with
the
architecture
that
I
was
trying
to
implement
so
because
it
was
blocking-
and
I
had
to
do
a
lot
of
work
around.
I
had
to
switch
around
a
few
tokyo
plug-in
libraries.
A
You
know
so
that
I
can
add
polling
retries
and
these
kind
of
things,
but
yeah
in
the
end,
a
separate
thread
for
streaming
and
switching
to
tokyo
streams
helped
helped
with
some
of
the
issues
that
I
was
facing.
So
there
are
still
some
goods
which
I
haven't
ironed
out.
Yet
I'm
assuming
that,
as
I
learn
more
and
as
I
become
better
in
in
overall
rust
async
world,
I
can
fix
some
of
those
ua
was
initially
blocking
before
I
split
into
multiple
threads.
A
I
had
one
thread
for
everything
and
the
ua
was
you
could
notice
bottlenecks
on
the
ua,
because
the
ua
will
become
unresponsive
whenever
there
is
a
network
all
being
done
and
stuff
like
that,
so
splitting
into
multiple
threads
helped
with
that
yeah
and
and
another
issue
is
that
the
version
update
of
q
bars
because
q
bars
k.
It
is
open
api
and
anything
that
uses
these
like
any
other
library
that
uses
these
has
to
be
carefully
updated.
You
cannot
have
multiple
versions
of
k.
A
It
has
open
api
on
the
in
the
same
project
because
of
how
that
library
is
published.
It
can
only
support
one
kubernetes
version
at
a
time.
So
if
there
are
multiple
libraries
in
your
project
using
the
same
libraries,
then
you
will
have
issues
whenever
you
compile
you
have
to
play
around.
You
would
have
to
play
around
and
make
sure
that
it
works,
and
even
if
you
do
that
again,
when
some
library
updates
aversion,
it
could
break
again
so
that
that
part
is
still
a
bit
of
a.
A
What
you
call
like
a
challenge,
I
haven't,
found
a
proper
solution
it
for
one
of
library
that
I
was
using.
I
worked
with
the
author
of
the
library
to
know
like
like
to
find
a
solution.
We
have
some
sort
of
vocal
solution
which
works
for
now,
but
this
could
you
know
happen
for
anyone
I
would
assume,
so
I
think
that's
it
from
me.
Thank
you.
So
much
for
letting
me
share
my
experience
and
to
to
share
my
life
love
for
rest.