►
Description
Rust is a systems language ready for IoT. In this talk, we’ll learn how to move servos, make sensor measurements, and speak low-level communication protocols like SPI and I2C. When joined with high-level HTTP libraries, audiences will leave knowing how to create a fault-tolerant embedded device that’s accessible from the cloud. Examples use the Rust language and target the Tessel microcontroller platform.
---
For more go to https://rustfest.eu or follow us on Twitter: https://twitter.com/rustfest
Help us caption & translate this video!
http://amara.org/v/2FiY/
A
The
Internet
of
Things
involves
setting
up
monitors,
so
you
can
see
the
state
of
the
internet
of
things
right
now.
I
hi,
everyone,
I
love
being
the
talk
before
lunch
because
it
ends
in
once,
which
means
my
talk
always
has
a
good
ending
to
it.
So
hopefully
you're
all
psyched
for
that.
But
thank
you
for
letting
me
talk
here
today.
A
My
name
is
Jim
Ryan
I'm,
a
developer
from
the
US
I
lived
in
San
Francisco
for
two
years
and
then
most
recently
moved
to
Boston
and
that
entire
time
I've
been
working
on
developer
tools,
specifically
developer
tools
for
init
of
things,
devices
for
drones.
For
basically
any
problem,
we're
a
software
developer
would
say:
hey
I,
want
to
sense
that
or
talk
to
that
or
move
that
around
anything
outside
of
the
confines
of
what
a
computer
or
a
phone
can
do.
A
I've
been
interested
in
and
I
know
that
the
talk
has
servo
in
the
title,
which
is
also
the
name
of
Mozilla's
experimental
web
browser,
and
unfortunately
this
is
not
gonna.
Talk
about
servo
at
all,
so
I'm,
sorry
for
the
disappointment
and
I
think
that
this
is
actually
probably
one
of
the
first
rust
talks,
which
will
involve
servo
by
the
other
definition
of
the
name
like
the
hobbyist
motor,
so
hopefully
in
the
future,
I'll
make
it
up
to
you
and
talk
about
servos
talking
to
the
servo
browser,
or
vice
versa.
A
But
what
I
am
here
to
talk
about
is
how
do
is
rust,
interact
with
hardware?
How
does
rust
interact
with
circuits,
so
the
biggest
problem
in
hardware
is
I,
have
information
or
there's
something
that
I
want
to
accomplish?
How
do
I
talk
to
it?
And,
let's
imagine
that
you
have
a
laptop
with
rust
code
running
on
it
and
a
temperature
sensor
which
could
very
well
look
like
this,
like
an
embedded
temperature
sensor,
or
you
just
have
the
idea
that
I
want
to
go
ahead
and
see
what
the
temperature
in
a
room
is
well
connecting.
A
A
A
lot
of
software
developers,
probably
don't
have
an
analog
for
what
this
looks
like,
even
if
they
actually
go
out
and
develop
with
circuits,
especially
because
it's
rust
is
primarily
built
around
developing
for
laptops
right
now
and
then,
let's
say
I
even
solved
this
problem,
I
have
rust
code
and
I
am
talking
to
a
sensor,
and
this
is
happening
at
my
home
and
I
am
now
3,000
miles
away
and
I
would
love
to
know
from
my
mobile
phone
what
the
temperature
is
in
Boston
Massachusetts
at
my
house.
Is
it
really
cold
right
now?
A
Is
my
house
burning
down?
I,
don't
know
these
would
be
great
questions
to
find
out.
So
this
is
the
other
problem,
the
Internet
of
Things,
which
is
connectivity
and
most
likely,
if
you
actually
are
doing
circuits
you're
aware
of
microcontrollers
you're
aware
of
development
boards,
and
these
are
the
primary
way
you
would
talk
to
a
circuit.
Essentially,
a
microcontroller
board
is
a
breakout
board
with
its
own
CPU
on
it.
You
plug
it
into
a
computer,
and
you
use
that
you
actually
develop
for
that
target,
and
that
is
what
communicates
to
a
device.
A
A
lot
of
these
boards
have
different
pins
on
them.
Basically,
little
ports
would
say:
okay,
you
can
wire
this
to
a
circuit,
and
these
pins
do
various
functions.
Sometimes
they're
specialized,
sometimes
not,
but
there
are
a
lot
of
common
ones
which
you
might
be
familiar
with.
For
example,
at
one
end
of
the
spectrum
is
microcontrollers
here:
I
have
pictured
a
teensy
board
which
is
similar
to
an
Arduino
board
and
it's
a
microcontroller.
It
uses
one
from
freescale.
It
basically
has
32
pins
on
it,
which
you
can
program.
A
The
more
interesting
part
about
this
is
that
it
may
have
a
few
hundred
kilobytes
of
memory,
if
not
only
a
few
dozen
kilobytes.
It
is
a
completely
different
programming
model
to
what
you
used
to
on
a
computer.
It's
probably
single
threaded.
You
don't
really
have
to
worry
about
memory
races
because
you're
not
really
maintaining
ownership
of
different
overlapping
memory
spaces.
It's
actually
just
all
one
memory
space,
so
you
don't
really
need
a
lot
of
the
guarantees
that
Rus
provides.
You
and
I'll
talk
about
that
later,
but
it's
basically
a
very
exotic
programming
model.
A
At
the
other
end
of
the
spectrum,
you
have
microprocessors
a
good
example
of
this
would
be
the
Raspberry
Pi,
so
embedded
computer.
Very
often
it's
running
Linux
and
it
could
do
high-level
tasks.
So
let's
say
it
is
running
a
Python
science
library
or
maybe
it
is
actually
running
a
full-blown
GPU.
In
any
case,
the
microprocessor
also
has
its
own
GPIO
pins,
which
is
to
say
that
it
can
talk
to
a
circuit
and
the
biggest
difference
between
these
two
is
that
on
the
microcontroller
side,
reliability
is
key.
Predictability
is
key.
A
You're
doing
things
as
fast
as
a
processor
can
do
them
on
the
microprocessor.
When
you're
running
Linux,
you
have
a
scheduler,
so
things
are
basically
competing
for
memory
competing
for
time.
So
you
can't
do
real-time
things
most
often
on
a
microprocessor
when
you're
doing
something
built
on
like
a
standard,
raspberry
pie,
distribution.
A
So
for
the
past
few
years,
I've
been
working
on
a
project
with
several
other
people
called
tehsil,
and
it's
just
another
microcontroller
board,
but
I've
been
excited
by
it
because
it's
fully
open
source
hardware
and
for
our
particular
example,
it
actually
has
a
microprocessor
and
a
microcontroller.
So
we
can
get
the
best
of
both
worlds
or
the
worst
of
both
worlds,
as
the
case
may
be.
A
Essentially,
the
Tesla
project
is
I've
been
working
on
it
since
2013.
Originally
it
was
a
company
and
then
now
it's
just
a
open-source
group
with
a
small
steering
committee
and
which
otherwise
accepts
open
source
contributions,
and
we
designed
it
specifically
as
a
platform
for
IOT,
specifically
tailored
for
software
developers.
Originally,
we
targeted
nodejs.
All
of
our
libraries,
written
in
nodejs
are
command-line
tools,
etc
and,
more
recently,
because
rust
reached
maturity
with
1.0
we've
been
excited
to
say:
ok,
well,
let's
develop
an
environment
that
takes
the
same
tool.
A
Sets
of
rust
developers
are
using
cargo,
rust,
sea,
etc
and
bring
them
into
a
Mike
Rotolo
platform.
That's
really
easy!
So
the
trajectory
is.
We
found
a
lot
of
C
code,
low-level
C
code,
ported
it
to
JavaScript
and
are
now
porting
it
to
rust.
Each
time
learning
the
benefits
of
each
language
and
like
learning
a
lot
about
ourselves,
is
like
wow.
We
were
really
young
programmers
back
then.
A
Another
interesting
thing
about
this
is
that
it's
an
in
the
wild
use
of
target
JSON
developing
for
tehsil
is
actually
searching
the
boundaries
of
what
my
knowledge
is
about
rest
and
how
it
cross
compiles.
So
it's
been
pretty
exciting
to
say:
okay,
we'll
take
all
the
features
and
all
the
extensibility
of
rust,
marry
it
to
the
development
environment
that
we've
already
built
out
and
see
if
we
can't
get
the
best
of
both
worlds.
A
So
the
basic
hello
world
example
is
a
blinking
example.
We
want
to
blink
some
lights
on
and
off.
This
is
a
combination
of
command-line
tools
which
make
it
really
easy
to
get
started
on
it
and
the
Cardo
ecosystem.
So
we
can
create
a
directory.
We
can
CD
into
that
directory.
We
can
run
t2
in
it
and
say
the
target
language
which
now
is
rust.
This
has
actually
been
merged
in
and
this
will
create
a
sample
cargo
repository
just
like
cargo
in
it
would.
A
We
can
also
then
run
T
to
run
and
specify
the
name
of
the
cargo
tamil
file,
and
then
your
Tesla
lights
that
start
blinking
it'll
start
screaming
at
you
that
it's
blinking,
please
stop
it
if
you
can.
But
the
entire
point
of
this
is
that
we
leverage
the
cargo
ecosystem.
We
build
a
crate
out
for
you.
If,
from
here
on
out,
you
can
do
same
dependencies
that
you're
using
you
can
add
your
own
source
code.
A
You
could
build
it
into
your
existing
system,
so
we
really
want
to
leverage
the
tools
that
are
already
there
for
software
developers.
So
now
that
that
is
out
of
the
way
that
is
the
development
platform
I'm
talking
about.
Let's
go
back
to
basics
when
we're
talking
about
signals
and
servos
we're
talking
about
circuits
and
how
many
of
you
have
circuit
experience.
A
Also,
so
that's
about
50%
of
the
room,
maybe
a
little
lower
it
just
to
go
over
the
basics
of
circuits,
we're
talking
mostly
about
digital
locket
logic.
Digital
logic
means
that
there
are
high
values
and
there
are
low
values
and
they're
being
interpreted
in
some
way.
So
if
I
have
a
circuit
and
say
the
voltage
is
three
point
three
I
might
say.
That
is
what
I
declare
is
a
high
voltage
when
that
is
high.
When
that
signal
is
3.3,
volts
I
want
to
turn
a
light
on
and
then
similarly
I
say.
A
Oh,
when
the
circuit
is
zero,
volts
I
want
to
turn
the
light
off
and
the
way
this
works
is
that
you
can
get
close
to
three
point:
three
get
close
to
zero
volts.
Basically,
everyone
just
sort
of
agrees
that,
when
you're
close
enough
to
these,
these
will
be
represented
as
those
values,
but
this
match
is
really
cleanly
to
binary
values,
so
a
high
voltage
might
be
one
and
a
low
voltage
might
be
zero.
One
thing
about
this
is
that
you
can
actually
look
at
this
as
a
power
source,
not
just
a
signal.
A
So
if
I
wanted
to
blink
an
LED
on
and
off
I
could
just
switch
it
from
high
to
low
I
could
send
out
a
square
wave
which
over
time
would
just
switch
on
four
equal
parts,
3.3
volts
and
zero
volts
and
notice
that
this
is
happening
over
time.
So,
if
I
stretch
out
any
of
those
signals,
the
light
will
be
on
for
longer.
The
light
will
be
on
for
a
shorter
amount
of
time.
A
If
I
blink
it
fast
enough,
then
it
will
actually
be
imperceptible
to
the
human
eye,
but
there
are
a
lot
of
fun
tricks.
You
can
do
with
that,
but
in
bust
code,
this
actually
Maps
very
cleanly
to
what
we
might
want
to
say
is
a
imperative
way
of
generating
that
same
signal.
So
we
have
a
few
lines
to
set
up
at
the
beginning,
which
is
say:
okay,
we
want
to
get
a
port.
A
We
want
to
know
that
it's
there,
so
we
unwrap
it
and
we
want
to
select,
pin
zero
pin
zero
is
going
to
be
our
LED.
Pin
and
then
at
a
loop
we
can
say
we
want
to
turn
their
pin
high
sleep
for
a
second.
We
want
to
turn
the
pin
low
sleep
for
another
second,
and
this
will
generate
the
same
signal
that
we
just
saw
in
the
previous
slide.
Now
note
right
now
that
this
is
entirely
synchronous.
A
It's
actually
putting
the
thread
to
sleep
while
we
are
doing
this,
but
because
we're
on
an
embedded
platform,
it
doesn't
matter
about
wasting
clock
cycles
or
anything.
So
pins
can
also
be
inputs,
as
well
as
outputs.
An
output
pin,
says
it's
zero,
volts
or
3.3
volts.
An
input
pin
says:
is
this
value
high
or
low?
A
So
if
I
have
a
wire
which
is
connected
to
a
high
voltage
and
then
a
switch
in
the
middle,
that
switch
is
going
to
break
the
circuit,
and
so
when
I
press
down
and
a
button
I'm
literally
saying
here's
a
conduct
of
material
continuing
the
circuit.
So
now
I
read
it
as
a
high
value,
because
we
get
all
the
way
to
the
the
voltage
source
and
in
the
same
way
we
can
say.
Okay,
we
want
to
turn
on
an
LED
with
a
switch.
A
The
LED
on
is
switch
off
turn
it
low,
but
the
senseability
here
is
that
well,
if
I
don't
want
to
turn
an
LED
on
what
if
I
want
to
say
when
the
switch
goes
down,
I
make
a
post
request
to
tweet
that
I'm
home
and
say:
hey
everyone
I'm
home,
come
hang
out
with
me,
I'm
lonely.
It
give
me
friends
that
is
also
possible,
and
that
is
the
magic
of
hardware.
A
These
two
in
combination
allow
us
to
actually
talk
to
the
microcontroller
and
measure
something
about
the
outside
world.
So
what
does
i2c
look
like?
So
those
two
pins,
the
data
and
the
clock
pin
could
be
wired
to
the
protocol,
which
is
known
as
ITC,
which
is
a
protocol
dating
back
like
30
years,
and
this
is
a
basically
an
agreement
between
the
two
processors
about
how
the
signal
works
in
the
same
way
that
your
web
browser
every
server
in
the
world.
A
Your
SmartWatch,
your
pacemaker,
all
of
these
understand
HTTP
as
a
common
language,
and
even
though
at
the
root
of
it,
HTTP
is
just
plain
text.
It's
sort
of
similar
to
this,
where
there's
two
signals
and
the
way
they
modulate
each
other.
That
is
what
determines
what
the
signal
is.
So
on
the
clock
line.
You
can
see
it
go
in
a
square
wave
and
every
time
it
goes
up,
you
might
measure
a
value
on
the
data
line
not
to
go
too
much
into
this.
A
But
the
basic
agreement
here
is
that
when
the
data
lines
go
low,
the
processor
will
emit
seven
o'clock
bits
saying
the
address.
It'll
say
we're
trying
to
write
a
bit
and
then
the
the
IC,
the
accelerometer
will
write
back
and
say
good
and
then
we'll
write
another
byte
over
to
it,
and
then
the
IC
will
say
good
again.
There's
AI
to
C
is
much
more
complicated
than
this,
but
the
key
point
to
notice
about
this
is
that
it's
happening
at
a
hundred
kilohertz.
A
A
So
these
are
really
really
high
speeds,
and
not
only
are
they
hard
for
us
to
think
about
it's
probably
too
fast
for
us
to
do,
and
I
specifically
mean
that
when
you're
trying
to
do
these
Pro
communication
protocols
you're
not
just
going
to
be
sitting
there,
flipping
a
switch
on
and
off
in
order
to
say
what
the
sensor
should
read,
it's
actually
going
to
be
handled
by
something
much
lower
level.
Hardware
controllers
exist
in
every
piece
of
software.
A
They
existed
your
USB
controllers,
the
way
your
laptop
talks
to
your
LCD
screen
and
we're
just
gonna
tell
the
hardware
what
to
do
and
say
these
are
the
registers
we
want
written
to
do
some
black
magic
and
then
give
us
a
result,
whether
it's
the
input
that
we
wanted
to
read
or
the
output.
So
what
do
we
do
when
we
have
a
low-level
protocol
that
we
want
to
wrap
in
a
high
level
system?
A
We
write
an
API
for
it,
and
so
here's
that
same
example
of
gears
in
a
cellar
ometer,
and
how
do
we
dry
to
it?
This
is
using
all
the
lowest
level
primitives
that
we
want
and
skipping
down
to
it.
We
first
do
a
transfer
to
the
address
0
X,
1
D.
We
say
you
are
the
accelerometer
I'm
gonna
write
a
0
X
D
to
you.
Can
you
please
send
me
back
the
register
value
at
that
0
X
D
means
Who
am
I.
It
responds
with
0
X
to
a
by
agreement.
We
just
say
okay.
A
Well,
this
is
our
handshake
value.
We
know
we're
talking
to
an
a
seller,
ometer
great
and
then
in
the
next
line
we
can
say
another
transfer
read:
register
0,
X,
0
1
read
back
6
bytes
into
this
mutable
buffer,
and
then
we
parse
over
it
using
some
data
using
some
logic
that
was
specified
in
the
datasheet,
but
what
it
boils
down
to
is.
We
now
have
a
tuple
of
3d
acceleration
vectors,
depending
on
which
way
we
angle
the
Acela
romaker
value.
A
We
will
get
different
values
here
and
that
was
just
14
lines
of
code
to
pick
up
in
arbitrary
IC
that
we
found
on
Adafruit
or
Sparkfun
and
start
talking
to
it
and
rust.
And,
of
course,
you
might
look
at
that,
and
you
say:
well,
that's
pretty
ugly,
so,
let's
publish
create
around
it
and
let's
make
it
nicer
with
human
terms
like
creating
a
seller.
A
Ometer
expect
that
it
is
actually
connected
to
us
and
read
the
acceleration
and
you
could
go
to
crates,
do
right
now
and
download
the
seller
ometer
create
if
you
wanted
to
talk
to
it.
So
one
key
thing
about
rust
here
is
that
we
actually
have
a
very
strong
advantage
of
using
rust
over
any
other
system
language
that
I've
used,
especially
over
using
javascript
in
this
case,
we're.
Let's
imagine
I,
was
trying
to
write
to
the
same
thing.
A
At
the
same
time,
I
have
an
LED
and
I
want
to
send
it
high
or
low,
but
I
also
have
the
i2c
port.
So
I
want
to
send
its
signals
with
rust.
We
can
actually
say
these
are
mutually
exclusive.
You
can't
mutate
both
at
the
same
time,
so
we
may
have
an
i2c
port.
We
can
write
some
data
and
then,
if
we
want
to
accidentally,
send
a
high
value
because
we
want
to
turn
the
LED
on,
but
we
do
it
on
the
wrong
pin.
A
We
can
say
rust
can
prevent
us
from
doing
this,
and
then
we
could
go
out
of
scope
and
we
can
say:
okay,
we're
good.
You
can
go
ahead
and
write
to
that
pin,
but
basically
it
creates
very
fault-tolerant
systems
well
before.
Actually
we
have
to
run
any
code
on
the
device.
It
does
there's
anything
more
harrowing
than
trying
to
figure
out
why
something's
going
wrong
in
your
computer.
It's
probably
trying
to
figure
out
why
something's
going
wrong
in
a
circuit,
so
this
has
been
a
huge
boon
when
designing
this
API.
A
This
is
hack
without
fear.
This
was
also
the
quote
that
they
used
last
year
to
sort
of
summarize
the
rust
methodology
and
so
I
went
ahead
and
actually
started
hacking
away
at
things
power
chords
in
my
house
in
order
to
make
a
few
demos,
so
here's
a
power
cord
which
has
the
wire
stripped
on
the
left.
You
can
see
those
two
leads
pointing
out,
so
you
definitely
shouldn't
plug
this
in
and
touch
them
both
at
the
same
time
or
either
of
them,
but
they
do
plug
into
a
circuit
really
well
and
on.
A
A
So,
over
the
past
pretty
much
the
past
2
weeks
we
went
shopping,
we
bought
a
bunch
of
sensors
and
we
came
up
with
five
different
crates
that
exemplify
different
sort
of
sensors,
Bluetooth,
Low,
Energy,
Climate,
sensor
relay
and
servo,
and
so
for
the
first
example:
I
want
to
go
back
to
the
accelerometer
demo
and
say
I
want
to
check
the
temperature
of
our
home.
If
it's
too
hot
I
want
to
be
able
to
turn
on
the
air
conditioner
and
so
for
this
I'm
gonna
pick
up.
The
two
creates
the
temperature
sensor.
A
The
climate
sensor
is
actually
both
a
temperature
and
humidity
sensor,
but
we
only
have
to
use
one
of
them
for
now
and
then
for
the
other.
One
I
want
to
say
pick
a
relay.
A
relay
is
basically
a
very
high
powered
switch
and
you
write
to
it
either
saying
hi
to
turn
on
the
switch
or
low
to
turn
off
the
switch,
but
it
can
handle
large
voltages
of
one
end
without
damaging
your
tiny
little
micro
controller.
A
So
in
this
video
I'm,
basically
using
a
web
server
that
is
hosted
on
the
tehsil
and
I'm
going
to
go
ahead
and
hit
the
start,
cooling
button,
which
will
turn
on
the
relay
and
thus
turn
on
the
fan.
In
the
background,
and
so
you
can
see,
the
temperature
is
slowly
dropping
because
of
the
climate
sensor,
which
is
right
there
inside
of
the
tehsil
itself,.
A
There
we
go,
but
you
believe
me
anyway,
so
yeah
so
we're
actually
reading
live
temperature
data
and
you
could
Maya
imagine
if
I
was
a
mile
away
or
again
in
Berlin
and
actually
trying
to
measure
this
at
my
house.
I
want
to
be
able
to
go
home
turn
on
the
air-conditioner.
Thirty
minutes
before
I
arrive.
It'd
be
able
to
do
this.
So
a
very
simple
example:
using
a
microcontroller
and
a
few
sensors,
the
next
one
I
want
to
show
you
is
an
actual
use
of
the
servo.
A
So
a
servo
is
a
hobby
motor
that
can
turn
from
0
to
180
degrees
and
the
best
part
about
a
servo
is
that
it
can
turn
to
a
fixed
point.
So,
unlike
a
motor
where
you're
just
saying
okay
go
forward
or
go
backward
at
a
certain
speed,
servos
can
have
specific
positions
on
them,
and
this
one
is
actually
very
similar
to
the
demo
that
we
saw
earlier
today
where
it's
turn
on
a
light
automatically.
When
you
walk
into
a
room.
A
A
That's
like
20
lines
of
code,
and
that
was
just
an
example
of
okay,
entirely
Rus
code
running
on
something
embedded
that
is
doing
things
with
sensors
in
servos.
That
is
very,
like
applicable
to
our
daily
lives
like
we
are
developing
companies
around
these
IOT
concepts.
We
are
buying
new
products
around
these
IOT
concepts
and
so
in
true
rust
fashion.
We
have
to
ask
ourselves:
are
we
IOT
yet
is
rust,
ready
for
the
Internet
of
Things
and
I?
A
Don't
want
to
give
a
definitive
answer
on
that,
because
I
am
just
a
developer
and
only
one
developer
and
there's
a
roomful
of
you
so
I
want
you
to
ponder
some
of
these
problems
in
IOT
that
we
have
right
now.
The
three
biggest
things
that
I
know
of
that
I
consider
problems
are
security,
reliability
and
power.
A
few
years
ago
we
have
the
shell-shocked
bug.
If
I'm
not
mistaken,
was
the
bug
that
allowed
you
to
do
a
buffer
overrun
in
a
router.
A
So
essentially,
if
you
sent
a
malformed
HTTP
header
to
a
router,
it
would
run
past
the
buffer
that
had
allocated
for
that
and
you
could
get
remote
code
execution
on
it.
Now,
remote
code
execution
isn't
a
big
deal
itself,
but
the
idea
that
you
have
a
router
in
your
home
in
millions
of
homes
and
you
can't
update
those
well,
that's
a
huge
deal
and
when
they
can't
be
updated,
you
really
have
to
get
security
right.
The
first
time
by
making
sure
you
have
all
these
guarantees.
A
A
So
when
we're
talking
about
explicit
error,
handling
or
memory
safety,
or
even
the
ability
to
not
have
your
program
crash
at
random,
like
the
extreme
of
this,
is
that
one
day
this
might
actually
save
a
life
to
do
protective
quoting,
but
even
then
it
will
save
you
time
and
save
you
money
if
you're
not
debugging
these
things.
So
rust
is
a
worthwhile
investment
and
the
last
one
would
be
power
and
I
think
this
is
funny
because
we
talk
about
zero
cost
allocations,
and
these
are
hugely
important
when
you're
doing
benchmarks.
A
But
it's
very
important
when
all
you
have
is
like
a
few
kilobytes
of
memory
to
spare
and
I
think
when
Julia
Evans
said
at
the
end
of
rusts
camp,
how,
oh
sorry,
Russ
conf
how
rust
is
making
a
new
generation
of
systems
developers.
Well,
if
there's
going
to
be
a
new
generation
of
IOT
developers,
then
they're
gonna
run
into
these
problems
too,
and
it
makes
it
easier
when
we
have
the
choice
between
zero
cost
allocation
or
using
the
abstractions.
A
You
want
because
most
commonly
an
embedded
scenario,
it's
a
choice
between
zero
cost
abstraction
or
doing
it
completely
unsafely
and
hoping
it
works.
So
I'm
gonna
leave
us
off
with
not
some
problems
with
the
rust
ecosystem,
but
with
some
goals.
Essentially,
cross-compilation
has
been
like
a
gold
standard
for
rust.
Right
now.
The
standard
lid
is
compatible
across
linux,
OS,
x
and
windows.
We
also
have
maya,
which
sort
of
sets
the
baseline
for
working
on
all
these
different
operating
systems.
A
So,
if
you
imagine
you're
writing
a
library
having
cross-compilation
capability
or
working
across
these
different
platforms
is
extreme
nice
to
have,
but
there's
also
more
platforms
than
that
and,
as
rust
keeps
being
brought
to
more
and
more
systems
that
it
becomes
more
popular.
We
really
should
think
about.
Ok.
Well,
what
is
it
going
to
be
this
constant
trek
uphill
trying
to
support
all
these
systems?
Is
it
something
we
can
maintain?
Is
it
something
that's
overbearing?
A
The
project
is
any
synchronous
systems
that
make
doing
low,
sorry,
zero
allocation
memory,
sorry
zero
allocation
event
loops
on
computer's
possible,
which
is
an
amazing
boon
for
anyone
writing
high-performance
code.
But
if
you
look
at
a
low
embedded
system,
you
may
not
even
have
the
option
to
use
threads
so
as
we're
going
forward.
Can
we
balance
this
idea
of
having
a
synchronous
systems
for
high
performance,
but
also
being
able
to
target
low-power
embedded
platforms?
It
still
offered
them
something
convenient
out
of
the
RUS
standard,
library
and
laughs.
A
There
were
a
lot
of
goals
for
rust
in
2017,
I
think
another
one
would
be
to
see
rust
at
its
lowest
level.
There's
a
lot
of
embedded
OS
projects
in
rust
right
now,
including
zinc,
including
talk,
there's
also
a
whole
slew
of
PCOS
is
coming
out
and
there
are
Hardware
projects
in
rusts,
specifically
designed
to
do
what
I
just
demonstrated
today
to
talk
to
circuits
near
Sisyphus,
which
is
available
on
Linux
and
Raspberry
Pi.
A
This
serial
de
RS
for
doing
hobby
robotics
are
talking
to
Arduinos,
there's
tehsil,
rust
and
there's
more
in
the
server
the
sensor,
libraries
that
I
wrote
today.
Currently,
only
work
on
one
platform
going
forward.
Can
we
design
a
foundation
that
brings
all
these
different
things
together
and
if
we're
able
to
do
that,
then
I
think
rust.
Where
previously
we
would
pick
C++
for
robotics
C
for
embedded
systems,
it
may
be
JavaScript
for
Internet
connected
systems
like
servers
and
browsers.
A
We
might
see
rust,
fill
all
of
these
niches
in
a
very
compatible
way
and
actually
make
rust
one
of
the
premier
languages
of
the
internet
of
things,
and
that
would
be
an
amazing
goal
for
me
and
I
hope
you
share
that
idea.
Thank
you
very
much
for
letting
me
talk
today.
You
can
see
any
of
the
code
demos
at
rust,
fest
2016.
You
can
see
what
I'm
currently
working
on
at
Tesla,
slash,
tehsil
rust
and
go
enjoy
your
lunch.