►
Description
Lowering the barrier for new Rust developers or library users is something I have always been passionate about. I believe that with WebAssembly and new compiler tools we can - and should - achieve better and easier explanations of complex concepts in our demos, code snippets, and documentation.
More at https://rustfest.global/session/17-learnable-programming-with-rust/
A
B
B
B
But
before
you
can
run
this
example,
you
need
to
make
sure
that
a
mini,
ready
server
is
actually
running
on
your
machine.
So
you
also
need
to
figure
out
how
to
install
and
run
it.
But
why
don't
we
try,
including
all
the
necessary
dependencies
right
there
on
the
same
page,
so
that
a
user
can
immediately
run
this
code
and
see
the
results.
B
B
B
B
B
This
model
is
then
executed
in
your
web
browser,
and
you
can
see
the
output.
This
approach
can
be
expanded
way
beyond
just
tokyo
or
any
other
single
library,
because
we
can
use
it
to
enhance
documentation
that
is
produced
by
rasdog
automatically
and
all
code.
B
But
what
if
we
make
it
simpler
by
running
examples
in
the
browser
on
the
same
page
and
showing
the
output
besides
the
code,
this
will
make
it
easier
for
people
to
just
immediately
see
the
output
without
switching
the
context,
but
there's
a
problem.
If
we
go
beyond
the
standard
library
now,
so
the
the
problem
is,
how
do
we?
How
do
we
deal
with
dependencies
and
especially
those
dependencies
which
don't
compile
into
web
assembly
yet?
B
Well,
the
thing
is,
we:
don't
really
have
access
to
dependencies
on
the
ros
playground
either,
because
ross
playground
has
a
limited
set
of
crates
available
to
us,
since
it's
an
isolated
environment
and
that's
an
expected
thing,
because
the
rust
playground
executes
your
code
on
their
server
and
they
just
want
to
make
sure
that
this
code
is
not
malicious.
So
they
limit
things
like
input
and
outputs
or
loading
the
external
dependencies.
B
But
on
the
other
hand,
this
is
this
also
makes
it
harder
for
us
and
makes
it
practically
impossible
to
run
examples
from
private
code
bases
or
even
from
public
crates,
and
it
makes
it
harder
for
us
to
mentor
and
educate
people
through
examples.
B
Webassembly
does
not
have
this
problem,
because
the
sandboxed
environment
is
not
someone
else's
machine
or
server,
but
it's
your
own
web
browser
and
this
sandbox
is
secured
by
definition,
but
the
main
problem
remains
not
all
rust
code
compiles
down
to
possibly
yet
well,
some
of
it
does,
but
even
if
it
doesn't
well,
you
can
argue
that
this
is
a
good
thing,
because
if
you
want
to
add
this
kind
of
interactive
from
this
kind
of
interactivity
to
your
project,
it
will
also
incentivize
you
to
make
to
make
your
code
more
portable
and
make
it
compilable
into
to
a
new
target.
B
B
Usually
what
you
want
to
do
is
to
is
to
mock
it,
meaning
that
your
code
won't
really
send
real
network
requests.
But
instead
it
will
pretend
to
do
so.
So
you
can
test
the
you
can
test
the
behavior
of
your
code
in
isolation
from
the
external
environment,
and
that
is
exactly
the
same
thing
that
we
want
to
do
with
our
interactive
documentation
to
because
we
want
to
give
a
user
the
option
to
run
their
code.
B
Independence
of
the
external
of
the
external
environment,
and
the
main
thing
to
look
for
here
is
the
api
conformance,
because
we
want
to
make
sure
that
mock
functions,
that
we
call
have
the
exact
same
interface
as
your
real
code
and
well.
You
can
do
this
manually
by
using
feature
flags,
for
example,
or
you
can
use
one
of
the
many
rust
libraries
for
automatic
mocking
and
but
the
the
main
idea
remains
that
you
that
you
want
to
provide
the
same.
The
same
interface,
both
in
your
real
code
and
in
the
mocked
version.
B
And-
and
this
idea
of
running
the
playground
code
in
the
browser
can
can
go
a
lot
further
because
we
have
lots
of
techniques
for
visualizing
data,
so,
for
example,
for
example,
on
this
slide,
you
can
see
some
code
from
the
documentation
of
an
http
client
library
called
request.
B
It
sends
a
get
request
and
outputs
the
response,
but
this
example
demonstrates
only
the
only
the
abstract
idea
of
sending
an
http
request,
but
how
do
we
know
how
it
actually
works
and
what
kind
of
request
it
actually
sounds.
B
So
in
this
case
we
can
output
the
the
http
requests
and
it's
really
helpful
to
see
what
kind
of
request
gets
sent
when
you
execute
this
code,
because
it
can
help
you
to
learn
more
about
http
and
more
than
that,
it
can
also
help
you
to
debug
problems,
because
with
an
interactive
playground
like
that,
you
can
just
replace
the
code
with
your
own
code
and
observe
the
changes
and
observe
its
behavior.
B
And
the
good
news
is
that
a
lot
of
frost
libraries
already
do
something
like
that
with
tracing
and
logging,
but
to
use
that
you
also
have
to
choose
a
logging
library
and
enable
it
to
just
get
the
logo
output
and
with
webassembly
enabled
playgrounds.
We
just
need
to
provide
our
own
logging
library
that
will
redirect
output
from
the
logs
to
to
a
user's
browser.
B
And
the
user's
code
can
be
can
also
be
seen
as
as
data
that
we
can
visualize
and
inspect,
and
some
of
the
components
of
the
ras
compiler
are
already
available
as
libraries,
and
there
are
even
some
more
creates
that
can
be
used
for
parsing
the
ros
code
and
almost
all
of
them
can
be
built
into
webassembly.
So
we
can
parse
the
code
and
extract
the
context,
information
that
we
can
use
to
show
hints
to
to
our
user
even
before
they
execute
their
code.
B
B
And
this
is
possible
because
the
compiler
provides
us
with
meta
information
about
about
the
function,
names
and
types
that
are
used
there
and
all
the
kinds
of
all
kinds
of
expressions,
and
it's
really
straightforward
to
work
with
code
as
data,
because
all
expressions
are
actually
variants
of
one
large
enum.
So
you
can
use
pattern
matching
to
work
with
this
enum,
just
as
you
would
normally
do
with
rust,
and
there
is
one
more
thing
that
we
can
do
here
and
that
is
highlighting
the
code
execution
flow.
B
It
can
be
compared
to
how
you
work
with
a
debugger
which
can
go
through
a
program
step
by
step,
and
while
it
goes
through
the
program
in
this
fashion,
it
also
can
show
the
internal
state
of
the
program
at
this
particular
point
in
time,
and
we
can
do
the
same
thing
for
our
interactive
playgrounds,
because
it
can
really
help
in
understanding
the
cases
like,
for
example,
long
iterator
chains.
B
It's
still
hard
to
see
what
kind
of
output
we
will
get
when,
for
example,
we
call
the
filter
function
on
the
on
the
third
line,
but
we
can
give
a
user
a
tool
to
go
through
this
example
line
by
line
while
also
showing
what
each
function
will
do,
and
we
can
also
combine
this
technique
with
the
others
we
have
discussed
so
far,
because
this
time
we
can
have
access
not
only
to
the
static
context,
information
that
is
provided
by
the
compiler,
but
also
to
the
dynamic
state
at
this
at
the
runtime,
and
we
can
display
data
like
local
variables
or
function
call
results
and
as
a
user
steps
through
the
code,
it
becomes
really
easy
to
see
how
the
state
changes
with
each
function
call
with
asynchronous
code.
B
We
can
record
the
state
at
each
step
and
store
it,
so
we
can
move
not
only
forward
but
also
backwards
in
time
and
since
we're
talking
mainly
about
things
like
short
snippets
of
code
and
examples,
instead
of
like
large
code
bases,
it's
possible
to
give
a
user
a
kind
of
a
slider
to
go
back
and
forth
to
really
see
the
execution
flow,
or
they
can
just
jump
straight
to
to
a
point
in
time.
That
is
interesting
to
them.
Just
by
clicking
on
the
slider
and
again.
B
This
is
this
is
not
some
sort
of
magic,
because
even
if
we
don't
have
an
immediate
access
to
the
webassembly
execution
engine
in
the
browser-
and
we
don't
have
a
kind
of
fine
grained
control
over
the
execution,
we
can
transform
the
user's
code
during
the
compilation
step,
and
we
can
do
that
even
without
modifying
and
touching
the
ras
compiler.
B
B
This
is
known
as
a
continuation,
and
it
means
that
we
can
continue
the
execution
of
a
function
from
the
point
that
we
left
it
at
and
rust
has
an
unstable
feature
called
generators,
and
this
feature
is
actually
used
for
implementing
the
async
await
syntax
and
well.
It
works
almost
exactly
as
you
see
it
on
this
slide,
so
we
have
a
struct
that
holds
the
internal
state
and
things
like
local
variables
and
each
block
is
transformed
into
a
separate
function.
B
B
And
so
far
we
have
discussed
some
implementation
details
for
these
ideas,
but
overarchingly.
How
do
we
actually
make
it
work
and
how
to
make
it
accessible
to
everyone?
B
So
it's
not
it's
not
that
big
of
a
deal
and
yeah
well,
so
I
tried
implementing
these
ideas
in
production
for
for
a
systems
programming
course
and
well
surprisingly,
this
infrastructure
is
not
really
it's
not
really
hard
to
provide,
and
it's
not
expensive,
because
a
single
cpu,
cpu
optimized
virtual
machine
can
easily
handle
hundreds
of
thousands
of
compilation
requests
per
day,
but
still
they
need
to
make
sure
that
this
infrastructure
is
easily
available
and
it
should
be
possible
to
deploy
it
to
to
deploy
this
comfort,
this
compilation
service
locally
and
privately,
but
there
is
another
problem
that
we
that
we
have
discussed
briefly.
B
If
we
start
to
include
dependencies
in
our
small
code
snippets,
the
compilation
will
take
a
large
amount
of
time
and
resources
and
the
resulting
web
assembly
module
can
have
a
huge
size
easily
taking
up
to
several
megabytes,
making
it
harder
to
scale
and
well.
The
obvious
solution
here
is
to
compile
these
dependencies
as
separate
webassembly
modules
instead
and
then
link
the
dependencies
when
we
need
them.
B
It's
possible
to
make
two
webassembly
modules
work
together,
so
each
module
consists
of
functions
that
it
exports
and
that
would
be
our
rust
functions
and
it
also
has
functions
that
are
declared
as
imported,
and
these
imported
functions
are
provided
by
the
caller
and
usually
they
are
used
for
calling
javascript
functions
from
the
ros
code,
and
this
is
what
makes
it
possible
for
rust
programs
to
interact,
for
example,
with
john
and
browser
functions.
B
What
we
can
do
is
to
call
an
exported
function
from
ros
module
b
and
this
works,
but
this
approach
works,
but
there
is
another
problem
with
it.
Each
model
has
its
own
separate
memory,
and
this
memory
is
not
shared
between
the
modules
and
this
means
that
if
an
imported
trust
function
tries
to
access
its
state
when
it's
executed
in
the
context
of
a
different
model,
it
will
fail,
because
this
memory
region
does
not
contain
the
expected
data.
B
So
now
that
we
have
covered
all
this,
what
is
the
conclusion?
B
I
think
that
it
is
well
worth
the
effort
to
make
our
to
make
our
documentation
interactive,
because
it
will
help
us
to
bring
more
people
into
rust
and
part
of
the
reason
why
javascript
is
so
popular
is
that
it's
so
easy
to
to
use
it
and
access
it?
You
don't
need
to
do
any
sort
of
complicated
setup.
All
you
have
to
do
is
to
open
a
console
in
your
web
browser,
and
you
already
can
start
writing
code
and
experimenting
with
it
and
with
webassembly.
B
We
have
a
really.
We
have
a
really
good
chance
of
bringing
this
of
bringing
this
simplicity
into
the
ross
world,
but
we
still
have
a
long
way
ahead
of
us,
because
the
web
assembly
ecosystem
has
not
has
not
matured
yet,
but
still
we
can
try
our
best
in
making
this
as
easy
as
possible
to
add
these
sort
of
interactive
elements
to
any
project,
because
we
already
have
tools
like
crossdock,
which
can
generate
documentation
out
of
the
source
code.
B
The
good
news
is
that
we
don't
have
to
start
from
scratch.
The
most
crucial
part
is
actually
compiling
the
code
into
the
assembly,
and
the
rust
compiler
has
got
us
covered
there.
We
just
need
to
build
a
tooling
around
it,
so
I
have
started
a
project
that
contains
the
docker
image
for
the
compiler
service
and
some
front-end
components.
You
can
find
the
repository
at
the
address
you
see
on
the
slide.