►
Description
This presentation was recorded at GOTO Copenhagen 2018. #gotocon #gotocph
http://gotocph.com
Katharina Fey - Software engineer at Ferrous Systems
ABSTRACT
Async IO, network programming and microservices have become a popular application of the Rust programming language.
This talk will give an introduction into these subjects and highlight why people are choosing Rust over other options.
The talk presents specific language features, like the concurrency-aware type system, as well as libraries that have emerged in the [...]
Download slides and read the full abstract here:
https://gotocph.com/2018/sessions/587
RECOMMENDED BOOKS
Tim McNamara • Rust in Action • https://amzn.to/3ux2R9u
Blandy, Orendorff & Tindall • Programming Rust • https://amzn.to/3x7r6w6
Ken Youens-Clark • Command-Line Rust • https://amzn.to/3PQZ539
Kevin Hoffman • Programming WebAssembly with Rust • https://amzn.to/3x3brhe
https://twitter.com/gotocph
https://www.facebook.com/GOTOConference
https://www.linkedin.com/company/goto-
http://gotocon.com
#Rustlang #AsyncProgramming #Rust #Programming #ProgrammingLanguage #SoftwareEngineering #Mozilla #Coding #FP #FunctionalProgramming
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at http://gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
https://www.youtube.com/user/GotoConferences/?sub_confirmation=1
A
All
right
so
hi
welcome
to
my
talk.
Thank
you
for
coming.
I'm,
gonna,
I'm,
gonna,
say
up
front
something
this
slide
says
async
and
Rus
2018
and
the
the
talk
description
might
say
something
about
features
and
async
async'
features
and
2018
rust.
But
this
talk
really
is
the
history
of
how
it's
rust,
2019
so
be
warned
right
before
I
get
started,
Who
am
I.
A
A
So
this
is
a
rusted
talk,
so
one
would
think
that
I
do
some
rust
things.
I
am
a
contributor
to
the
the
CLI
working
group,
which
is
a
group
of
people
that
sort
of
exists
close
to
the
core
team
that
deals
with
developing
CLI
libraries
and
making
the
development
of
CLI
applications.
Nicer.
I
am
a
member
of
the
community
team
and
Berlin
RS,
which
is
sort
of
a
local
community
group
in
Berlin.
We
organize
events
and
workshops.
A
I've
been
I've
given
rust
bridge,
which
is
a
one
day
workshop
organized
by
or
around
Mozilla
events
to
teach
trust
to
people
underrepresented
in
technology
twice
now,
once
in
Paris
and
once
in
Portland
and
I
maintain
a
bunch
of
libraries.
So
if
you're
writing
CLI
is
chances,
are
that
you're
using
my
code
and
if
you're,
not,
then
you
probably
won't
have
to
so
I
want
to
start.
This
talk
with
a
hopefully
very
uncontroversial
statement,
which
is
that
concurrency
is
really
hard.
A
We
there's
two
different
types
of
concurrency
problems
that
you
usually
encounter.
The
ones
is
the
cars
jumping
over
each
other
and
the
other
one
is
not
enough
cars
going
over
the
same
road
now,
not
enough
cars,
so
inefficient
scaling,
usually
isn't
a
big
problem
except
that
you're
wasting.
You
know,
hardware
resources,
but
they
don't
generally
cause
any
bugs.
What
is
the
problem
or
race
conditions,
as
you
saw
in
a
literal
race,
so
race
conditions,
I'm
gonna,
give
a
little
bit
of
a
primer
on
a
few
concurrency
issues.
A
A
If
you're,
not
careful,
depending
on
the
timing
on
how
your
threads
are
going
to
be
executed
by
your
scheduler
either,
if
the
value
is
going
to
be
one
or
it's
going
to
be
two,
and
only
one
of
those
is
the
correct
answer,
the
other
one
is
a
data
race
that
makes
you
lose
data,
and
this
is
exactly
where
we're
rust
comes
in.
So
I
normally
speak
more
at
a
trust
conferences
where
I
can
assume
that
people
generally
understand
what
the
language
is
about.
A
So
rust
is
a
systems
programming
language
that
runs
blazingly
fast,
prevents
seg
faults
and
guarantees
thread
safety.
That
is
the
marketing
pitch
on
the
website
and
I.
Think
the
correct
response
to
that
is
to
be
a
little
confused,
because,
while,
if
you're
in
the
systems
programming
world
already-
and
you
might
be
familiar
with
a
lot
of
these
concepts,
there
is
a
lot
of
jargon
there
and
so
to
break
down
word
rust
is
really
about.
A
There
is
one
word
that
summarizes
certain,
which
is
safety:
that's
safety
in
two
different
domains;
memory
safety
for
one
rust
was
developed
as
a
replacement
for
C++
and
Firefox,
and
there
is
a
few
other
design
decisions
that
come
from
that,
for
example,
very
easy
interoperability
with
C
code,
which
can
can
be
quite
fun,
and
the
second
thing
is
thread
safety.
So
a
lot
of
concurrency
issues
revolve
around
what
thread
owns
data
and
well
rust
makes
this
very
explicit
with
ownership.
So
in
rust
all
data
has
an
owner
and
all
data
is
always
owned.
A
Let's
take
this
piece
of
code
and
I
again,
I,
don't
know
how
many
people
here
actually
I
would
like
to
see
how
many
people
have
programmed
rust
in
this
room
before.
Okay,
that's
about
five
percent,
maybe
okay,
so
the
syntax
should
be
fairly
straightforward.
Two
things
I
will
mention
is
this
question:
mark
is
a
way
to
gracefully
propagate
errors
upwards,
so
F
in
this
case
will
either
be
of
by
all
or
the
function
will
be
exited
early
with
an
error.
A
It's
the
let
something
error
and
if
error
return
era
from
go,
I,
don't
write
much
go
ever
but,
like
I've,
seen
this
pattern
and
like
a
lot
of
people,
know
that
pattern,
there's
no
exceptions
and
Russ.
So
this
is
how
you
deal
with
errors.
You
can
just
sort
of
say:
ok,
this
is
now
a
file,
and
if
the
file
opening
failed,
then
the
function
will
return
an
error.
A
The
second
thing
that
you
might
be
a
little
confused
by
whoops:
ok,
calm,
the
move
with
the
pipes,
so
the
pipes
open
a
closure
with
curly
break
versus
being
the
actual
function.
Move
in
this
context
means
that
the
environment
of
the
closure
is
captured
in
a
mutable
sort
of
way,
which
is
important.
If
you
want
to
then
change
anything
about
it.
And
so,
if
you
look
at
this
code,
this
is
not
correct.
A
This
will
not
work
and
in
any
other
language,
this
would
cause
a
runtime
issue,
whereas
in
rust
it
just
doesn't
compile,
it
doesn't
compile
because
of
ownership,
because
the
first
time
this
thread
is
invoked.
It
takes
ownership
of
the
value
F
and
then
F
is
dropped,
which
is
the
equivalent
of
closing
a
file,
but
so
the
next
time
you
would
want
to
do
anything
which
is
literally
the
loop
and
the
compiler
understands
that
the
thread
is
being
spawned
in
a
loop
it.
A
The
the
ownership,
has
already
been
moved
into
the
first
thread,
so
you
can't
do
that
and
it
won't
compile
and
to
simplify
this
this
example
a
little
bit.
This
would
also
not
compile.
So
we
have
a.
We
have
some
function
read
from
file
which
just
takes
a
file
and
it
does
whatever
and
then,
if
you
want
to
open
a
file
and
read
from
it
twice
or
call
this
function
twice,
this
would
also
not
compile,
for
the
same
reason,
the
reason
being
that
you
try
to
move
ownership
instead
of
borrowing
the
data.
A
You
know
a
Java,
Script
or
a
Python
background,
and
they
did
mostly
scripting
or
whatever
or
the
other
way
around.
So
so
with
that
out
the
way
I
hope
you,
you
have
a
bit
of
a
picture
about
what
rust
is
and
why
it's
interesting.
Let's
talk
about
async.
What
is
that?
What
does
it
know?
It
doesn't
know
anything
and,
let's
find
out
so
async
programming
for
people
who
don't
do
async
programming
can
be
a
little
confusing
because
it
boils
down
to
this
sentence.
A
One
of
them
is
futures
and
we're
gonna
look
at
what
not
those
types
of
futures,
but
futures
are
calculations
that
haven't
happened
yet
so
when
with
async
programming,
non-blocking
I/o
or
non-blocking
operations
generally
become
speculating
about
what
will
be
in
the
future
and
in
most
languages
this
is
called
literally
a
future.
Although
javascript
Koston
promises,
it
means
that
something
is
probably
going
to
happen
at
some
point
and
you
just
should
keep
asking
it.
A
And
the
interesting
thing
here
is:
whenever
I
talk
to
people
who
don't
don't,
have
a
familiarity
with
async
programming
and
I
tell
them
this.
They
asked
me
well.
Is
that
not
just
a
thread
and
a
joint
handle
and
I
mean
in
a
way
I
like
spawning
a
thread
and
then
waiting
for
that
thread
to
terminate
and
do
something
and
give
you
something
back
has
similarities
to
that.
But
the
big
difference
is
the
event
loop,
so
futures
run
inside
an
event
loop,
which
means
that
it's
a
it's
a
scheduler.
That
runs
your
features.
A
It
is
responsible
for
pulling
the
futures
for
readiness
and
then
calling
whatever
code
that
you
want
it
to
call
call
when
a
future
becomes
ready.
This
is
this
can
be
seen
as
a
user
space
scheduler
for
well
futures
now
event
loops
can
be
multi-threaded,
but
they
don't
have
to
be
by
definition.
They
can
be
single.
A
Threaded
nodejs,
for
example,
is
a
single
threaded
event
loop
and
what
it
means
is
that
it
takes
all
of
the
responsibility
of
scheduling
your
application
and
takes
it
from
the
developer
of
the
actual
application
and
puts
it
on
to
the
developer
of
the
event
loop.
So
why
would
you
want
to
do
this?
It
boils
down
to
complexity
of
context.
Switching.
A
So
when
you
spot
a
new
thread,
that's
a
lot
of
work.
It
there's
a
lot
of
overhead
involved.
You
have
to
allocate
memory,
you
have
to
copy
registers
around
your
kernel
needs
to
do
a
lot
of
legwork
and
there's
a
syscall
involved.
So
you
know,
all
of
this
requires
a
bit
of
dedication
if
you
spawned
a
thread
for
literally
every
call
that
you
do,
your
application
would
be
a
lot
slower,
because
you
have
so
much
overhead
that
you
never
see
the
returns
or
you
have
diminishing
returns
from
spotting
threads.
A
A
But
fundamentally,
Apache
spawns
is
much
more
eager
to
spawn
new
threads
when
dealing
with
connections
than
nginx
nginx
usually
allocates
a
pool
of
workers,
and
it
can
you
know
it
can
grow
that
if
it
needs
to,
but
it
uses
async
programming
paradigms
to
use
the
threads
that
it
already
has
in
the
workers
that
it
already
has
with
more
efficiency
and
well.
You
can
see
this
in
the
memory
usage.
A
This
is,
for
example,
also
the
reason
why
nginx
is
basically
immune
to
the
slow
lorry,
a
dose
or
DDoS
attack
where
you
open
connections
to
a
web
server
and
then
just
let
them
time
out
in
order
to
like
make
the
servers
for
lots
of
workers
and
where
nginx
does
just
in
care
right.
So
I
hope
that
you
have
a
even
if
you
weren't
familiar
with
async
programming
before
I
hope.
You
understand
what
it's
about
and
with
the
the
history
of
rust
in
mind
or
a
little
bit
of
context
about
rust
in
mind.
A
A
Lib
Green
was
introduced
into
the
the
rust
standard
library
at
December,
26
2013,
for
the
development
efforts
before
that,
we're
obviously
already
and
in
place,
and
so
there
were
two
threading
directives
and
and
schedule
schedule.
Schedule
errs
essentially
for
further
adds
one
that
used
sort
of
these
asynchronous
non-blocking
micro
threads
and
the
other
one
that
actually
bounds
like
a
one
to
one
system
thread.
A
This
enabled
the
the
rust
standard
library
to
do
non-blocking
I/o
and
do
a
lot
of
asynchronous
programming
very
early
on
the
problem
is
or
the
problem
was
that
that
required
the
standard
library
to
actually
include
a
run
time
or
a
run
time
for
an
event
loop
for
these
features
or
for
asynchronous
there
wasn't
a
futurist
abstraction.
Yet
it
was
just
generally
asynchronous
calls,
and
this
came
with
a
lot
of
problems
and
like
a
lot
of
them,
are
specific
to
how
the
rust
compiler
was
implemented
and
how
the
rest
of
the
standard
library
was
implemented.
A
But
ultimately,
the
decision
to
remove
this
again
was
because
rust
wanted
to
go
into
a
different
direction.
Rust
didn't
want
to
have
to
rely
on
a
runtime
and
wanted
to
be
more
low-level
and
bare
metal.
So,
just
a
year
later,
in
late
2014
November
21st
2014
lip
green
was
removed,
and
so
it
was
dead
and
very
soon
after
people
wanted
to
have
a
sink
I/o
again,
and
so
this
project
me
ors
started
which
stands
for
metal
I/o
and
what
mio
or
me
ORS
allows
you
to
do.
Is
it
allows
you
to
do
non-blocking
I/o?
A
There
is
plugins,
essentially
for
me,
oh
so
that
you
can
have
asynchronous
I/o
on
all
sorts
of
different
well,
not
just
platforms
but
devices
realistically
and
so
yeah.
This
is
something
that
the
community
kept
developing
it
it
just
maintained
by
a
few
people
in
the
core
team.
So
it's
not
just
like
the
community,
but
Missoula
is
putting
its
weight
behind
it.
So
yeah
before
we
go
any
further.
There
is
a
second
concept
or
a
technically
third
I
guess.
If
we
count
borrowing
and
ownership
is
two
different
concepts.
A
One
way
that
I've
heard
it
be
explained
is
that
a
zero
cost
abstraction
has
no
discernable
runtime
overhead,
and
that
sounds
interesting.
But
then
it
makes
me
ask
the
question
in
comparison
to
what
run
time
so
like
if
you
compare
some
rust
code,
that
is,
zero,
abstraction,
zero
cost
abstraction
to
the
Java
JVM
and
well,
of
course,
you
know
your
costs
are
going
to
be
different
than
your
runtime
caustic,
not
gonna,
be
comparable.
So
a
much
better
way
to
look
about
it.
A
Look
at
it
is
that
it
is
code
that
you
can't
have
written
better
by
hand.
Even
if
you
tried
and
there's
gonna
be
I'm
gonna
talk
about
an
example
in
a
second,
so
basically,
what
a
zero
cost
abstraction
is
is
an
abstraction
that
disappears
at
compile
time.
It
is
a
concept,
a
type
that
the
compiler
knows
about
in
the
first
few.
Steps
of
you
know,
compilation
that
the
borrowed
checker
knows
about
that.
A
A
In
fact,
sometimes
because
type
information
can
be
traced
through
certain
parts
of
the
compile
steps.
Sometimes
the
iterator
API
is
actually
faster
than
writing
a
for
loop,
because
the
compiler
can
do
things
like
cache
locality
that
you
know
you
could
otherwise
not
assume,
because
you
have
a
greater
scope
so
which
brings
us
to
May
2016.
This
point
rust
had
been
stable
for
about
a
year,
and
a
library
emerged
that
would
change
asynchronous
programming
forever,
which
is
futures
RS.
A
You
can
see
a
theme
and
the
memes
and
the
slides,
so
futures
RS
is
a
zero
cost
abstraction
for
futures,
so
the
same
thing
that
you
can
do
for
iterators
and
a
for
loop.
If
you
use
this
futures
library-
and
you
build
these
these
future,
these
async
tape
machines.
Essentially,
you
can
be
guaranteed
that
the
code
that
ends
up
in
your
binary
has
no
allocation
overhead
and
no
runtime
overhead
in
comparison
to.
If
you
had
written
it
all
yourself
and
you
were
hand
optimizing.
A
This
exact
scenario
that
you
know
you've
you've
programmed
into
your
computer
and
like
you're,
doing
all
of
it
yourself.
I,
don't
want
to
go
as
far
as
say
hand,
written
assembly,
because
I
do
like
the
LLVM,
but
I
don't
have
faith
in
its
optimizations
that
much,
but
you
can
be.
You
can
be
guaranteed
that
you
could
not
write
non
assembly
code
yourself,
any
better
if
you
use
a
this
abstraction
which
is
brilliant
and
it
allowed
a
second
project
Tokio
core.
A
So
we
defined
standard
in
and
standard
out
outside
the
code.
I
didn't
want
the
code
block
to
be
too
big.
We
we
define
a
reader
and
we've
defined
a
buffer.
The
the
reader
is
a
buffered
reader
over
standard
N
and
the
buffer
is
a
vector.
A
vector
in
rust
is
a
heap
allocated
data
structure
which
grows
with
different
sizes.
So
if
you
add
things
to
it,
it
will
grow
and
if
you
remove
them
again,
it
will
shrink,
depending
on
what
it
feels
is
appropriate.
A
But
under
the
hood,
it's
implemented
as
an
array,
not
a
linked
list,
so
to
build
a
future
with
the
futures
library.
You
can,
for
example,
say
well,
let's
read
until
some
thing,
so
we
read
until
we
hit
a
new
line.
The
B
just
says
that
it's
a
binary
string
and
we'd
read
it
into
buffer
and
when
this
happens
and
now
you're
building
a
future
or
you're,
attaching
some
piece
of
information
to
the
future.
A
As
you
know,
maybe
you
want
to
read
more
and
the
buffer,
but
what
we
do
is
we
ignore
standardin,
and
we
write
two
standard
out
the
contents
of
the
entire
buffer
map
error
by
the
way,
in
this
case,
just
like
math
error,
you
panic
means
that
if
there
is
any
kind
of
error
we
don't
want
to
gracefully
handle
it,
we
want
to
panic
and
run
out
the
room
with
an
error
message,
and
the
same
applies
down
here.
I
am
NOT
doing
well
with
selecting
things
today.
A
This
map
error
here
is
essentially
the
alternative
to.
If
the
reading
process
hits
any
sort
of
problem,
your
pipe
goes
away
or
whatever
then
it'll
also
panic.
Okay,
so
we
defined
a
future.
But
the
interesting
thing
here
is
that
this
is
just
some
type
information.
This
is
a
collection
of
data
types
again
which
will
disappear
in
a
minute,
and
this
is
actually
where
this
gets
wrong.
A
Tokyo
is
the
event
loop
of
our
choice
here,
and
we
give
Tokyo
this
future
and
Tokyo
will
now
make
sure
to
keep
reading
from
standardin
and
call
our
future
chain
whenever
it
is
ready
and
that's
basically
like
this
is
the
basics,
and
you
can
expand
this
really
easily.
You
could
do
TCP,
like
you
could
read
from
from
a
TCP
socket
instead
of
like
standard
in
the
api's
are
the
same.
You
could
read
from
a
serial
port
if
you
wanted,
which
is
kind
of
cool
if
you're
embedded
so
like
this
is
the
these.
A
Are
the
basic
building
blocks
of
of
building
building
async
applications,
and
really
the
thing
to
to
remind
yourself
of
here
is
that
all
of
this
type
complexity,
all
of
the
combinators-
and
you
know
you
have
a
closure
and
you
jump
into
some
code
and,
like
you,
you
do
whatever
this.
Just
that
disappears
at
compile
time
and
what
you're
left
with
is
very
bare
metal
code.
That
is
highly
optimized.
A
The
interesting
thing
about
the
ownership
model
here
is
that
we
access
reader
and
buffer
and
both
reader
or
reader
I,
guess
is
only
accessed
by
the
first
step
part,
but
buffer
is
then
passed
on
to
the
next
Combinator.
Both
of
these
values
are
handed
over
to
the
to
the
beginning
of
the
future
chain,
and
so
this
future
now
owns
the
the
data,
which
means
that
when
we
pass
this
entire
future
to
Tokyo
Tokyo
owns
this
data.
A
What
that
means
is
that,
if
you,
if
your
code
gets
run,
you
can
be
sure
that
you're
the
only
like,
because
of
the
way
that
ownership
works,
you
can
be
sure
that
you're
the
only
function
in
your
application
that
accesses
buffer.
At
the
same
time,
if
you
were
to
put
this
into
a
loop
or
sorry,
if
you
were
to
run
Tokyo
in
on
multiple
threads,
then
this
wouldn't
work
anymore,
because
it
would
tell
you
the
exact
same
error
message
that
we
got
with
the
thread.
Saying
hey.
A
You
just
moved
ownership
into
this
one
thread
and
you're
trying
to
spawn
seven
more
that
this
doesn't
work,
and
at
that
point
you
need
to
make
like
you
need
to
explicitly
make
sure
that
the
data
structure
says
you
use
our
thread.
Safe
I
haven't
gone
into
that
at
all,
because
that's
a
whole
can
of
worms
or
it's
a
very
complicated
issue,
and
it's
it's
something
that
when
you
learn
rust,
is
something
you
have
to
get
used
to.
But
the
point
is
concurrency
issues
here
are
being
made
explicit.
A
So
so
far
so
good,
this
talk
was
entitled
rust,
20,
18
and
not
rust
2013
to
2016,
something
that
has
happened
this
year
as
part
of
rust
2018
as
async/await.
So
rust.
2018
is
a
marketing
release.
It's
actual
version
number.
If
I
remember
correctly,
it's
gonna
be
one
point
31,
because
I
think
one
point
thirty
is
currently
out.
So
it's
still
backwards
compatible
with
all
the
rest
code
that
you've
written
and
seen
and
whatever
the
way
that
features
and
new
features
are
being
enabled
and
features
are
being
liked.
A
Even
a
few
breaking
features
are
enabled
with
an
on
an
opt-in
basis,
so
you
can
declare
your
project
as
being
a
rust,
20,
18
project
and
then
a
rust,
2015
compiler
would
no
longer
understand
these
features
as
part
of
that
and
pretty
interesting,
actually
how
you
can
combine
rust,
2015
and
2018
libraries
into
the
same
project.
The
compiler
can
on-the-fly
switch
between
whichever
it
needs
to
so
it
has
like
different
run
modes.
A
So
there's
not
going
to
be
a
dependency
chaos
where
your
dependencies
can't
be
used
because
you're
using
the
new
version
and
they're
using
the
old
version
that
still
works.
As
part
of
this
development
effort,
there
were
a
few
working
groups
that
were
created
and
a
few
pushes
for
stabilizations
and
features
were
made
and
async/await
was
one
of
them.
So
the
idea
behind
it
is
basically
the
same
as
there's
a
few
other
languages
that
do
it.
This
way
write
code
that
looks
like
synchronous,
normal
blocking
code,
but
which
really
isn't
which
uses
an
event
loop.
A
There
is
this
a
weight
macro
which
you
call,
which
then
interacts
implicitly
with
the
runtime
that
you
previously
set
up
explicitly
and
that
way
you
can
write
code
that
is
basically
a
weight.
This
thing
awaits
this
thing:
do
these
things
like
asynchronously
and
then
await
all
three
of
them
or
something
a
lot
of
things
become
possible?
This
way,
and
it
it
generally
cleans
up
the
code
that
you
write,
because
you
don't
end
up
having
these
huge
state
machines
because
yeah
they
can
be
really
cute,
but
sometimes
they'd
become
a
little
large
and
they
become
unmaintainable.
A
And
this
way
you
can
avoid
this.
So
how
does
this
work?
It's
kind
of
complicated
and
clever
people
are
working
on
it
in
groups.
You
might
even
call
them
working
groups,
which
is
the
networking
working
group.
So
this
is
a
bunch
of
people
either
from
the
rust
core
teams
themselves
or
peripherals,
so
like
I,
am
in
the
CLI
working
group
and
I'm,
not
on
the
core
team.
A
Who
is
people
who
implement
these
features
in
the
compiler
and
provide
a
library
ecosystem?
The
way
that
this
works
is
that
this
futures,
abstraction
that
I
showed
you
earlier
has
moved
into
the
standard
lab
at
Lib,
core
or
parts
of
it
have
moved
into
Lib
core
of
the
language,
which
means
that
you
can
use
all
of
these
features
to
some
extent,
even
on
embedded
microcontrollers,
where
you
don't
have
access
to
the
standard
lab,
because
it's
too
big
for
it
and
then
there's
their
certain
API.
A
Is
that
run
times
and
like
event,
loops
can
use
to
make
themselves
compatible
to
this
to
the
syntax
so
that
you
actually
have
a
have
a
choice
which
runtime
you
want
to
use.
You
can
use
Tokyo.
If
you
know
it's
a
general-purpose
good
runtime.
If
you
were
running
on
some
quirky
embedded
device,
you
can
either
use
an
embedded
runtime
of
one
exists
or,
if
you're
a
company,
and
you
need
to
like
specifically
target
one
device.
A
You
can
write
your
own
and
you
can
still
be
compatible
with
all
of
the
other
future
stuff,
which
means
that
you
can
take.
You
can
take
advantage
of
all
the
work
that
other
people
are
putting
into
the
futures
ecosystem
so
well,
yeah.
Can
you
use
this
and
the
answer
is
kind
of
so
the
async/await
syntax
itself
is
a
stable
or
stable-ish
in
the
nightly
compiler.
It
requires
a
feature
flag.
A
Its
usage
hasn't
changed
in
the
last
few
months
and
as
preparation
to
this
talk,
I've
interviewed
a
few
people
who
are
working
on
it
and
they
don't
expect
it
to
change
very
much.
So
you
know
chances
are
that
if
you
start
writing
some
code
using
this,
it's
not
gonna
break,
but
you
know
you're
still
living
a
little
dangerously
with
the
nightly.
A
The
problem
is
the
library
ecosystem,
namely
that
event
loops
are
missing
that
useless
or
their
usability
isn't
perfect,
yet
I,
guess
and
realistically
the
first
few
months,
like
January,
February
March,
something
like
that
in
2019
is
supposed
to
be
when
this
becomes
stable.
There
were
a
few
delays
throughout
the
year
when
it
came
to
a
few
other
blocking
issues
on
the
compiler,
which
is
why
this
is
all
a
little
late,
which
means
that
it's
not
officially
in
this
umbrella
term
of
frost
2018,
all
right
and
that's
it
I
thought
my
talk.