►
Description
RustConf 2018 - Space, The Rusty Frontier by Ryan Plauche
Space. It is often thought of as the final frontier for humans. Why not also for Rust?
In the fall of 2017 we began using Rust on an upcoming CubeSat mission. Writing safe, performant software is a high priority for us, one shared by the aerospace industry. Our software framework was originally written in C but we wanted to explore other options which could give us more confidence in our code and allow us to leverage newer technologies. For us Rust fits the bill with its emphasis on safety, growing community, and high level software patterns.
This presentation will cover the finer points of why we settled on Rust, how we integrated Rust into our existing C environment, how Rust has affected our developer productivity, pictures of the (first?) spacecraft running Rust in low Earth orbit and thoughts on the future of Rust in Space.
A
A
This
is
more
of
the
story
of
the
company
that
I
work
for
and
how
we
have
come
to
use
rust
and
why
we
like,
using
rust
in
the
different
places
that
we
use
it
so
don't
expect
any
deep
technical
dives,
which
honestly
is
a
kudos,
I
think
to
the
rust
team
and
that
we
didn't
have
to
do
any
deep
technical
work
with
rust
to
make
it
fit
into
our
product.
As
is
it
was
good
and
it
worked.
So
this
is
more
of
a
high
level
how
we
got
there
and
what
we
do
with
it.
A
A
You
know
wrestling
with
tooling
and
really
weird
bugs
and
all
the
things
that
come
with
that
environment,
so
using
rust,
is
a
is
a
breath
of
fresh
air
for
me,
but
I
spent
a
lot
of
time,
not
using
rust
and
I
understand
the
issues
that
come
up
with
other
languages
and
other
environments,
the
company
that
I
work
for
we
are
called
Kubis
and
we
build
software
solutions
for
satellites.
So
we
we
operate
in
what
you
would
call
the
the
new
space
sector,
which
is
I,
think
kind
of
started
by
SpaceX
in
this
commercialization
of
space.
A
And
now
you
have
all
of
these
these
different
startups
appearing,
and
we
want
to
position
ourselves
to
really
help
those
companies
operate
their
satellites
or
their
spacecraft
really
well
by
providing
quality
software
products
that
they
can
use
and
of
them
having
to
reinvent
all
this
software.
Every
time
they
go
about
doing
a
mission,
so
our
goal
is
to
make
space
more
accessible
and
we
do
that
by
lowering
the
barriers
of
entry
associated
with
software
in
space.
A
Now
what
we
found
is
that,
with
a
lot
of
these
companies,
you
know
they're
made
up
mostly
by
electrical
engineers
and
aerospace
engineers,
which
makes
a
lot
of
sense
right.
A
spacecraft
is
this
complex
piece
of
hardware
that
you
have
to
be
very
careful
about
and
it
operates
in
space.
So
clearly
you
want
a
lot
of
knowledge
around
those
two
things,
but
often
the
software
is
kind
of
left
til
the
end,
or
maybe
it's
like
a
poor
ee,
who
doesn't
really
write.
A
A
lot
of
software
is
now
in
charge
of
writing
all
the
software
to
run
their
satellite
and
that's
not
a
really
fun
position
to
be
in
when,
let's
say
your
satellite
launches
in
two
months,
so
it's
like
go
go,
go,
get
it
all
done,
so
we
want
to
provide
tools
to
empower
these
people
and
increase
their
chances
of
success
with
their
missions.
We
have
two
products
that
we
we
work
on
to
do
that.
A
The
first
one
is
called
Major
Tom,
and
this
is
just
our
mission
control
software
I'll
talk
about
this
one
too
much
today,
because
it's
not
really
the
focus
of
this
talk.
It's
a
it's
a
Ruby
on
Rails
back
in
with
react,
front-end
pretty
standard
web
app.
It's
what
you'd
use
on
the
ground
to
receive
data
from
your
satellite
and
send
commands
up
to
your
satellite
I,
understand,
there's
a
pretty
big
overlap
in
this
community
and
the
Ruby
community.
A
So
I
thought
it'd
be
neat
to
highlight
that
we
do
use
Ruby
on
our
other
product
and
we
are
also
looking
for
engineers
to
help
with
this
product.
So
if
this
seems
interesting
to
you,
please
come
talk
to
me
after
this
and
we'd
be
glad
to
talk
to
you.
So
the
main
product
that
I
work
on
and
the
thing
that
will
be
the
focus
of
this
talk-
is
what
we
call
cube
OS.
Now
it's
a
little
confusing
because
the
name
of
our
company
is
cubis.
A
The
name
of
this
product
is
cube,
OS
and
you
know
part
of
why
we
name
it.
That
way
is
because
it
is
the
complete
flight
software
system
and
it's
a
flight
software
framework
as
well,
so
for
the
systems
that
we
support.
We
package
a
custom,
Linux
distribution
that
supports
the
hardware
and
then
various
pieces
of
middleware
that
are
custom
tailored
to
satellite
specific
needs,
drivers
that
are
pre-built
for
peripherals.
That
satellites
will
use
and
then
a
framework
for
our
customers
that
build
on
top
of,
as
they
implement
the
logic
for
their
missions.
A
So,
let's
talk
about
how
we
got
to
rust,
I
think
we
have
to
step
back
a
little
bit
first
and
recognize
that
at
the
base,
satellites
are
all
just
really
fancy
embedded
systems.
They
usually
have
some
form
of
constraint.
Now,
maybe
they
operate
in
a
pretty
exotic
environment
like
a
little
different
than
most
of
our
embedded
systems
here
on
earth.
It's
just
a
little,
and
you
know
some
of
the
hardware
that's
connected
to
them
is
a
little
different,
but
in
the
end,
when
it
comes
to
writing
the
software
you're,
essentially
working
on
an
embedded
device.
A
Trying
to
pull
this
all
together
and
put
it
under
you
know
one
unified
front
for
our
customers
to
work
with,
because
that's
not
really
something
that
exists
in
the
C
world.
There
are
a
lot
of
different
tools
that
do
a
lot
of
different
things,
but
not
always
a
lot
of
unity
among
those
tools
and
a
lot
of
continuity
between
those.
A
We
did
build
a
lot
of
that,
but
being
a
start-up
trying
to
figure
out
our
identity
and
what
our
product
was
and
what
to
do
with
it
eventually
over
time
you
find
that
things,
change
and
Along
Came
Linux
and
really
changed
things
for
us.
So
we
found
that,
as
we
talked
to
more
hardware
vendors,
we
realized
that
the
the
flight
boards
they
were
offering
they
were
pretty
powerful,
they
could
run
Linux
and
a
lot
of
the
customers
that
we
were
talking
to.
A
A
It's
so
much
easier
to
program
in
Linux,
it's
so
much
easier
for
us
to
find
developers
and
our
customers
to
find
developers
to
work
in
a
Linux
environment,
and
it
opens
the
door
for
all
sorts
of
other
languages
to
be
used
when
we're
building
on
free
artists
see
was
basically
the
only
choice.
I've
seen
some
work
and
building
for
our
toast
modules
in
rust,
which
is
really
cool,
but
it's
pretty
rare
for
the
most
part
you're
going
to
be
writing
in
just
C.
A
A
The
other
thing
was
just
thinking
about
si
and
its
place
in
our
product
and
in
the
industry
at
different
conferences.
Where
we
would
talk
about
our
software.
We
would
often
get
very
pointed
questions
about
how
do
you
deal
with
the
error
rates
of
see?
How
do
you
deal
with
the
dangerous
side
of
see?
You
know?
How
do
you
make
this
safe
for
people,
and
there
was
one
person
who
asked
me
a
lot
of
questions
and
his
answer
was
always
well.
A
You
should
use
ADA
and
well
it's
not
exactly
that
simple
to
just
use
ADA,
but
him
asking
these
questions
really
got
them
bouncing
around
on
our
head
thinking.
Okay,
you
know,
is
this
really
the
best
thing
for
us
and
then
starting
to
consider
who
our
customers
were?
And
you
know
what
is
the
best
thing
for
them?
What
can
deliver
the
best
product
for
them
when
your
customers
are
a
bunch
of
people
that
yeah
they
can
write
software,
but
they
are
not
necessarily
professional
software
developers.
A
So
sure
si
is
easy
for
them
to
pick
up,
but
is
it
really
safe
for
them
to
pick
up?
Is
it
really
the
right
thing
for
them
to
be
running
with?
Can
they
make
the
best
choices
with
Si,
not
having
a
lot
of
training
and
a
lot
of
practice
writing
software,
and
we
started
to
realize
that
maybe
the
answer
is
no,
maybe
C
was
not
the
best
choice
for
us,
so
I
think
it's
good
to
answer
this
question.
A
Why
not
ADA
at
this
point,
because
in
the
aerospace
industry
ADA
is
a
really
popular
choice
and
I
think
as
a
language,
it
actually
has
a
lot
of
good
to
it.
I
spent
some
time
tinkering
with
ADA
as
as
we're
wrestling
with
this
question
of,
should
we
use
C
or
you
know,
what's
better,
what's
worse
and
as
a
language,
it's
cool.
The
community
I
found
is
mainly
hidden
behind
closed
source
barriers.
A
We
could
not
find
a
big,
thriving
open-source
community,
which
is
something
that
we
wanted
to
be
able
to
align
with,
but
really
the
tiller
for
us
is
the
licensing
situation
with
Ada.
As
far
as
I
can
tell
there's
one
company
that
kind
of
supports
the
ADA
compiler
and
the
main
libraries.
So
you
have
two
options:
you
can
either
purchase
their
commercial
license
or
use
their
open-source
license,
and
that
compiler
and
all
the
standard
libraries
are
under
the
GPL.
A
So
then
everything
you
write
is
then
GPL,
which
neither
is
those
options
really
work
that
well
for
us,
as
a
company
trying
to
produce
a
commercial
but
also
open-source
product,
so
that
really
nixed
ADA
for
us.
So
the
the
thing
that
really
made
us
jump
into
rust
was
graph
QL.
This
is
probably
last
fall
last
summer.
A
And
we
found
that
in
the
C
world
there
was
like
one
or
two
craft,
qo
libraries,
but
there
wasn't
a
graph
QL
engine
that
really
worked
with
the
HTTP
server
and
I
really
didn't
want
to
write
that
myself
that
just
sounded
awful
when
there
were
so
many
implementations.
Already
in
other
languages-
and
we
saw
that
rust
had
great
support
for
graph
QL
fit
in
with
the
type
system
that
rust
had
I
worked
well
with
the
HTTP
server.
So
did
some
tinkering
with
that.
It
seemed
good.
A
We
did
kind
of
a
bake-off
internally
between
C,
rust
and
Python
to
see
what
direction
we
wanted
to
go
in
with
our
core
fight
software
and
in
the
end,
for
a
variety
of
reasons.
Rust
won
out.
So
at
this
point,
I
can
say
pretty
confidently
that
it
Q
Bose.
We
don't
write
a
new
C
there.
There
are
C
products
that
we
still
maintain.
You
boot
is
the
main
bootloader
we
use,
which
is
written
in
C
and
we
will
not
be
rewriting
u-boot
and
rust.
A
So
now
I'm
going
to
talk
a
little
bit
about
what
I
call
the
joy
of
rust,
they're
just
different
things
that
we've
come
to
appreciate
about
rust.
You
know
some
of
these
things
were
ideas
that
won
us
over
before
we
started
using
rust
and
others
were
things
that
we
have
just
discovered
as
we've
gone
and
now
really
appreciate.
A
So
to
start
with
high
level
tools,
low
level
performance
I
find
that,
with
rust
between
things
like
traits
modules,
the
whole
enum
system
options
results.
The
whole
standard
library
rust
helps
me
think
about
software
when
I
write
it
in
a
much
more
natural
way
than
sita's.
I
often
found
that
with
C,
as
I
tried
to
take
my
thoughts
about
software
and
translate
them
into
the
language.
It's
going
from.
You
know
high
level
design
to
okay.
How
do
I
organize
this
around
the?
A
I
think
it
helps
with
design
so
much,
but
we
don't
lose
on
performance,
which
is
even
better,
so
you
kind
of
get
get
the
best
of
both
worlds
right
then,
that's
that's
the
point
of
this
now
I
do
want
to
say
real,
quick
that
I'm
not
here
to
bash
C.
That's
just
the
context
that
I
come
from.
That
is
my
history.
A
So
the
next
great
thing
about
rust,
the
compiler
protections
that
we
get
and
I
won't
go
into
this
too
much,
but
just
that
you
know
the
strong
ding
and
the
memory
management
and
the
way
the
compiler
will
protect
you
and
just
really
yell
at
you
and
get
on
to
you
if
you're
doing
bad
things
and
just
knowing
that,
if
I
can
please
the
compiler
that
my
code
probably
isn't
going
to
seg
fault,
it's
probably
not
going
to
have
some
weird
pointer
errors.
That
is
like
such
a
huge
load
off
of
our
shoulders.
A
Knowing
that
you
know
if
our
CI
system
passes,
our
code
is
probably
mostly
good,
it
will
mostly
work.
It
may
not
do
what
we
want
it
to
do,
but
it's
not
going
to
do
the
wrong
things
in
a
bad
way
and
that's
just
great
ok,
error
handling.
This
is
one
of
our
favorite
things
about
rust,
gosh.
We
love
that
we
can
actually
handle
errors
using
rust.
A
The
idea
that
there
is
a
result,
type
that
can
return
either
my
data
or
an
error
type,
is
so
cool
that
I
can
propagate
those
errors
back
up
to
the
top
level.
Through
all
my
call
stack,
it's
even
better
and
the
fact
that
that
can
be
done
with
like
the
lowly
question
mark,
which
is
genius,
it's
so
great
that
we
can
do
this.
We
are
patiently
watching
the
error
handling
story.
You
know
following
failure,
trying
to
figure
out.
Ok,
where
is
this
going
to
go
using
the
latest
versions
but
yeah?
A
A
Documentation.
Documentation
is
something
we
take
pretty
seriously
at
Kubo's.
We
write
a
lot
of
it
and
we
love
that
cargo
has
built-in
support
for
rust,
dock
and
building
those
docks,
but
even
more
so
we
love
that
we
can
embed
rust
in
our
docks
and
the
compiler
will
tell
us
if
those
examples
are
still
relevant
if
they
still
work.
So
it
helps
us
keep
our
documentation
to
be
a
living
artifact.
You
know
living
part
of
the
code
and
that's
super
valuable,
especially
as
a
company
that
is
building
a
product
intended
for
use
by
other
people.
A
The
whole
point
of
the
product
I
work
on
is
that
I
shouldn't
have
to
write
code
for
other
people.
They
should
be
able
to
use
my
code
and
then
go
off
and
do
their
own
things
so
documentation
working
examples.
This
is
all
super
important
for
achieving
this
goal
of
empowering
other
people,
and
just
this
ability
to
compile
the
examples
in
our
Docs
seem
so
small,
but
really
is
a
big
deal
for
us
that
that
we
can
keep
this
stuff
all
in
check.
A
Okay
and
lastly,
at
least
for
now,
though,
the
whole
tooling
story
of
rust
has
been
huge
for
us.
The
fact
that,
within
the
cargo
tool
through
different
plugins
and
through
its
existing
capabilities,
you
can
build
test
cross,
compile,
build
your
Docs
format,
your
code
gosh.
How
cool
was
that
that
it's
it's
all
in
one
tool
and
it's
all
built
by
the
same
community
I'm
not
like
going
across.
A
You
know
the
nether
regions
of
the
internet,
looking
for
some
Rando
GCC
toolchain
to
do
my
cross,
compiling
right,
it's
all
hidden
behind
one
tool
and
like
we
didn't
even
have
to
write
that.
That
is
something
that
the
rust
community
is
doing
and
building
and
maintaining.
So
thank
you
for
that.
We
love
it.
It's
so
great.
A
It
makes
our
lives
so
much
easier
and
honestly,
it's
a
lot
of
what
we
are
trying
to
do
previously,
with
our
C,
API
or
C
SDK,
so
seeing
it
done
and
rust
in
a
way
that
exists
already
really
well
and
that
we
can
easily
extend
it
through
the
cargo
plugins
system
is
just
great
all
right.
So,
let's
talk
a
little
bit
about
where
we
use
rust.
Call
this
Huber
s
corrosion.
So
we
are
slowly,
you
know
corroding
or
rusta
fiying
our
system.
A
A
You
know
below
your
radio
receiving
data
and
in
this
very
large
gray
box
that
says
flight
software.
Those
are
all
the
things
that
run
on
the
satellite
and
I
think
I
can
say
pretty
good
confidence
that
most
of
these
are
written
in
rust.
At
this
point,
there
are
a
few
pieces
that
aren't
written
in
rust.
We
use
some
Lua
footing
around
in
there
and
some
legacy.
A
C
and
a
little
bit
of
Python,
but
the
goal
is
that
everything
we
write
within
this
diagram
will
be
in
rust,
and
the
goal
is
that
when
we
deliver
this
software
to
our
customers,
that
we
know
we've
written
it
in
rust,
we've
done
our
testing.
We've
looked
at
it
very
thoroughly
and
we're
delivering
a
solid
product
for
them
to
build
on
top
of
now.
A
Maybe
our
customers
right
and
rust-
maybe
they
don't
but
the
pieces
of
our
software
that
we
had
built
that
they
rely
on,
they
were
gonna,
be
rock-solid,
and
part
of
that
is
because
we've
chosen
to
use
rust
to
write
them.
So
speaking
of
customers
does
rust
mix
well
with
our
customers.
This
is
an
ongoing
question.
I
think
one
that
we
will
find
the
answers
to
over
the
next
few
years,
as
we
we
slowly
explore
this.
A
But
what
we've
decided
to
do
is
give
our
customers
the
ability
to
either
write
and
rust
if
they
want
to,
and
some
of
them
do
and
they're
very
excited
about
using
rust,
which
is
really
encouraging
and
affirming
for
our
decision
to
go
that
way.
But
for
those
that
are,
you
know
less
familiar,
we
do
let
them
use
Python.
It
runs
alongside
rust
and
part
of
how
we
make
that
interoperate
is
in
our
architecture.
A
All
those
different
boxes
are
actually
different
processes,
so
we
create
Network
boundaries
between
each
process,
and
that
means
we
don't
really
have
to
worry
about
mixing
languages.
As
long
as
everything
speaks
the
same
DP
graph,
QL
mixture
that
we
have,
we
don't
care.
What's
talking
to
our
rust
services,
we
just
said
everything
bounded
at
the
network
layer
and
then
the
rust
services
are
responsible,
for
you
know,
sanitizing
whatever
comes
in
and
making
sure
it's
safe,
so
whatever
our
customers
right,
they
can't
take
down
they're
on
satellite.
A
So
the
first
one
and
this
kind
of
hits
us
pretty
hard-
is
the
compiled
binary
sizes.
It's
a
debug,
rust
binary.
It's
gonna
be
pretty
large,
a
release,
rust
binary,
it's
going
to
be
smaller
and
you
can
strip
it
down
to
be
even
smaller,
but
still
we
found
they
tend
to
be
a
little
bigger
than
the
SI
binaries,
and
that's
something
that
we
have
to
kind
of
reckon
with
on
a
daily
basis
as
we
do
development
on
these
satellites.
A
So
imagine
you
have
a
satellite
on
your
desk
and
you're
working
with
it,
but
the
only
way
you
can
talk
to
it
is
over
a
serial
link
and
it's
operating
like
1
1,
5,
200
bps,
and
you
have
a
one-and-a-half
megabyte
binary.
You
have
to
transfer
over
and
that's
your
only
way
of
doing
it.
So
that's
kind
of
slow.
It's
gonna.
Take
a
little
while
to
send
that
over
now.
A
That's
like
best-case
scenario
now
imagine
we
take
that
satellite
and
we
put
it
up
in
space
and
now
it's
talking
to
a
radio
over
that
serial
link,
but
the
radio
is
actually
even
slower
than
the
serial
link.
Let's
say:
half
the
speed
and
let's
say
like
you,
can
only
talk
to
it
for
like
three
or
four
minutes
every
10
minutes,
so
you've
lost
a
lot
of
bandwidth
this
at
this
point,
and
this
this
one-and-a-half
megabyte
binary,
suddenly
is
taking
a
really
long
time
to
transfer
over.
So
we
don't
have
a
good
solution
for
this
one.
A
Yet
we're
still
reckoning
with
this,
we
may
look
into
the
idea
of
binary
discs
or
something
like
that
when
it
comes
to
updates.
But
this
is
just
a
thing
for
us
that
that
we
all
have
to
deal
with
as
updating
software
and
satellites
is
a
real
need
and
something
that
we
really
want
to
offer
to
our
customers
user
learning
curve.
This
comes
back
to
the
whole
idea
of
for
us
as
the
customer,
but
really
it's
it's
any
new
user
of
rust.
A
There
is
certainly
a
learning
curve
to
getting
into
the
language
and
I
think
it'd
be
easy
for
someone
to
argue
that
C
is
much
easier
to
learn,
but
is
C
safer
to
on
I.
Don't
know
about
that,
I
think
we
pay
a
lot
upfront
when
we
learn
rust
for
the
safety
that
it
gives
us,
but
sometimes
we
have
to
convince
people
that's
worth
doing,
but
I
will
say.
We
really
appreciate
the
rust
community
and
the
work
they've
done
on
the
docks.
The
rust
book
has
been
great.
A
A
It's
not
a
good,
quick
solution
to
this.
One
I
think
the
best
solution,
though,
is
that
we
have
to
stick
with
rust
and
keep
working
on
it
and
keep
pushing
it
forward.
We
can't
abandon
it.
We
have
to
see
the
long
game
of
rust
and
not
in
the
long
term.
I
think
it
can
and
will
become
a
very
acceptable
default
for
systems
languages,
but
we
just
have
to
give
it
that
time
to
aged
and
mature
and
to
gain
the
trust
of
different
industries,
toolchain
maturity.
A
This
is
one
that
hits
a
little
closer
to
home
when
it
comes
to
embedded
systems.
So
if
you
go
the
rust
forage
website,
they
have
the
list
of
supported
platforms.
It's
actually
really
cool
to
see
all
the
different
platforms
that
are
supported
by
rust
in
the
different
tiers,
but
what
you'll
notice
is
that
the
tier
one
guaranteed
to
work
does
not
have
most
of
those
platforms.
Most
of
them
are
in
tier
2
or
tier
3
and
I.
A
Think,
as
we
push
more
into
different
exotic
pieces
of
hardware
and
I
say,
exotic
exotic
could
mean
like
a
PowerPC
which,
to
most
of
us
is
pretty
antiquated,
but
in
the
aerospace
industry
is
honestly
like
pretty
standard.
When
you
get
to
a
bigger
mission
that
needs
like
a
rat
hard
CPU
PowerPC
is
pretty
common,
so
to
say
right
now,
like
ok,
yeah,
you
should
use
rust.
It's
guaranteed
to
build,
like
all
that
stuff
is
guaranteed
to
build.
A
Lastly,
ecosystem
maturity,
I
think
this
and
the
torch
a
maturity,
language
maturity.
All
of
these
are
just
things
that
happen
with
time,
but
I
think
this
one
in
particular,
is
the
one
that's
most
in
the
hands
of
everyone
in
this
community.
The
one
thing
that
we
do
a
lot
at
Q
boss
is
testing
and
when
looking
for
a
testing
framework
in
rust,
it's
like
okay,
mock
testing
and
crates.
That
I
owe
what
do
we
get.
Maybe
we
get
like
five
or
six
different
libraries.
A
You
know
some
of
them
aren't
stable.
Some
of
them
are
nightly
so
like
which
one
do
I
pick
out
of
all
of
these,
and
you
know
maybe
some
appear
to
be
supported
really
well.
Maybe
some
startup
got
off
to
a
great
start,
but
now
it's
like
just
someone
maintain
it
I'm,
not
really
sure
trying
to
figure
out
what
is
the
best
choice.
Sometimes
it's
tough
I
think
as
a
community.
A
We
need
to
take
steps
to
be
better
better
contributors,
not
just
your
users,
I
think,
the
more
that
we
can
contribute
back
to
the
crates
that
we
want
to
use
and
I.
Think
a
lot
of
people
do
this:
it's
not
really
something
I
started
doing,
but
it's
something
I
really
feel
like
I
should
do.
I
can't
just
be
up
here,
saying
these
critical
things
and
not
taking
steps
to
fix
them.
I'm
part
of
this
community
too,
so
the
more
that
we
together
can
contribute
and
hold
up
and
support.
A
Okay,
so
closing
thoughts,
we
akibo
Sui,
really
like
rust,
I,
don't
think
it's
too
much
to
say
that
we
have
taken
a
decently
large
gamble
on
the
language
and
the
ecosystem.
Not
our
product
is
a
framework
we
are
chosen.
Rus
is
the
primary
language
for
that
framework,
so
I
think
that's
a
pretty
strong
statement
that
we
believe
in
rust
and
we
believe
in
its
future,
and
we
are
thankful
for
rust
and
all
the
different
libraries
and
the
people
that
support
it
and
want
to
continue
working
with
this
community
and
you
know
hopefully
growing
together.
A
So
thank
you,
for
you
know
the
great
gift
of
rust
that
you
have
given
us
and
given
to
so
many
people
and
now.
Lastly,
if
you
want
to
check
out
our
flight
software,
you
just
up
here
on
github,
so
please
go
out
of
my
rust.
Tell
me
I'm
a
terrible
programmer.
Please
help
me
get
better
or
you
know,
give
us
suggestions.
So
that's
all.
Thank
you.