►
Description
Cyrus Omar describes RustViz, a tool for annotating Rust code that can provide compiler-assisted visualization of ownership and borrowing patterns. RustViz was developed in conjunction with a large number of undergrad students, and has proven to be a successful teaching tool.
The RustViz source code is available at https://github.com/rustviz/rustviz. A full paper describing RustViz is available at https://web.eecs.umich.edu/~comar/rustviz-vlhcc22.pdf.
A
All
right,
so
this
is
a
project
that,
as
you
can
see
from
the
authorship
list
here,
has
been
a
project.
A
Actually,
it's
all
undergraduate
students
that
have
worked
on
this
project
other
than
myself,
so
I've
just
listed
them
in
alphabetical
order.
Here
some
of
them
were
core
staff.
Some
of
them
were
students
interested
in
the
topic.
I
do
want
to
particularly
shout
out
gabriel
wow,
who
came
up
with
sort
of
the
initial
design
for
this
thing,
so
I'm
excited
to
present
on
behalf
of
the
people
who
actually
did
the
work.
A
So
if
you
try
to
investigate
sort
of
how
people's
experiences
go,
when
they're
learning
russ
borrow
checker,
you
start
to
find
really
interesting
quotes
or
poems
almost
so
this
this.
This
poem
here
from
a
study
conducted
by
michael
coblins
and
colleagues,
says
learning
rust.
Ownership
is
like
navigating
a
maze
where
the
walls
are
made
of
asbestos
and
frustration
and
the
maze
has
no
exit
and
every
time
you
hit
a
dead
end,
you
get
an
aneurysm
and
die.
A
So
I
I
love
this
quote.
It
really
expresses
the
the
you
know
the
frustration
that
students
feel
in
navigating
this
so-called
alien
concept,
this
biggest
struggle
that
they
face,
and
you
know
the
the
phrase
fighting
the
bar
checkers
come
up
today
and
it
comes
up
all
over
the
place
on
the
web
when
people
discuss
these
things
ana
zing
and
will
have
an
interesting
paper,
just
kind
of
investigating
how
people
talk
about
those
things,
so
you
know
why.
Why
is
why
is
russ
so
tricky?
A
Why
is
this
ownership
and
borrowing
system
so
tricky,
and
you
know
just
just
from
kind
of
thinking
about
the
problem.
Looking
at
some
of
these
these
these
prior
papers,
you
get
this
sense
that
the
the
real
issue
is
that
there's
all
this
invisible
state,
that's
happening,
it's
sort
of
static
state.
You
know
who
owns
a
resource
when's
the
life.
You
know
how.
How
long
does
this
lifetime
extend?
A
You
know
what
capabilities
do
I
have
given
the
uniqueness
constraints
that
are
imposed
by
the
reference
system
and
all
of
these
all
these
pieces
of
invisible
state
and
the
rules
that
govern
them.
They
all
have
to
be
mentally
simulated
by
the
programmer
right,
so
they
have
to
learn
to
mentally
simulate
these
rules
and
then
keep
a
model
in
their
head
as
they
comprehend
attempt
to
comprehend
code
and
that's
a
very
complicated
thing.
A
A
lot
of
cognitive
load
is
incurred
when
you
do
that,
and
so,
if
we
want
to
build
tools
to
kind
of
lessen
that
cognitive
load,
a
general
principle
that
we
might
follow
is
to
make
visible
the
invisible
right
to
help
learners.
A
We
do
this
invisible
work
for
them,
instead
of
requiring
them
to
do
it
all
in
their
head,
when
they
still
haven't
really
figured
out
the
rules
themselves,
and
then
you
just
show
it
to
them
in
some
way:
that's
comprehensible
in
some
way
that
they
can
refer
to
and
engaging
in
a
couple
of
different
things.
One
you
know
as
they're
developing
this
mental
model.
A
These
visualizations
can
help
as
provide
scaffolding,
so
they
provide
the
vocabulary,
the
key
structures,
the
key
concepts
that
they
need
to
eventually
be
able
to
come
up
with
on
their
own
in
their
head,
but
until
they
do
that,
they
can
see
that
you
know
this
is
what
I
need
to
be
able
to
produce
in
my
head
and
then,
as
they
start
attempting
to
do
that,
as
they
start
to
develop
and
kind
of
try
to
apply
their
mental
model.
A
It
gives
them
a
way
to
take
these
sort
of
to
make
them
scientists
to
take
the
predictions
that
they're
generating
and
allow
them
to
immediately
verify
that
what
they
predicted
is
actually
what's
happening.
If
it's
not
visible,
there's
no
way
to
verify
your
prediction.
A
So
that's
a
lot
of
words.
I
think
this
is
a
general
principle
that
I
think
is
important
in
in
tool
design.
I
just
want
to
jump
into
a
demo
of
the
rustviz
tool,
which
is
focused
on
visualizing.
These
ownership
and
borrowing.
B
A
In
rust,
so
let's
switch
over
to
that
tab.
A
So
what
the
system
is
is
it's
a
system
for
including
visualizations
in
narrative,
instructional
narrative,
so
we
are
what's
based
on
the
md
book
system
that
a
lot
of
rust,
documentation,
rust
books
and
things
already
used.
A
So
you
can
see
this
is
an
md
book
tutorial
that
we've
developed
and
I'll
talk
more
about
how
we
integrate
it
into
our
classroom
and
everything.
But
this
is
an
introduction
to
russ.
It's
meant
to
be
kind
of
a
30
minute
introduction
to
rust,
designed
for
people
with
some
programming
background,
but
no
rust
background
and
as
we'll
go
through
some
of
the
tutorial
you'll
see
that
all
these
code
examples
will
have
alongside
of
them
this
visualization
and
it's
an
interactive
visualization
that
word
interactive,
is
maybe
doing
a
little
too
much
work.
It's.
A
Okay-
so
let
me
add
so
so
this
is
this
initial
example
is
meant
to
actually
showcase
a
lot
of
the
different
visualization
features
and
then
we'll
go
through
some
of
the
more
basic
examples,
but
you
can
see,
as
I
kind
of
hover
over
aspects
of
this
visualization,
both
the
visualization,
but
the
hover
message
shows
up
showing
you
kind
of
what
that
element
means,
and
then
you
see
some
changes
in
the
code
itself,
highlighting
in
this
case
the
corresponding
function,
string
from
and
underlining
the
line.
A
Just
so
you
know
which
line
you're
talking
about
then
you
can
see
what's
happening
here,
is
that
it's
visualizing,
a
move
of
a
resource
returned
from
string
from
and
moved
to
s,
and
then,
when
you
hover
over
this
kind
of
dot
event
on
s,
you
see
that
s
acquires
ownership
of
a
resource
and
then
from
there
on
out.
A
If
you
hover
over
this
line,
you
see
that
s
is
the
owner
of
this
resource
and
it
also
communicates
something
about
the
the
variable
s
being
mutable,
since
it
was
introduced
with
let
mute
so
the
binding
can
be
reassigned.
It's
kind
of
visualization
of
these
capabilities,
and
so
you
can
see,
there's
there's
more
of
that
for
different
things
like
borrowers
and
things
here
as
well,
so
that
that's
that's
the
that's
russ
fizz,
okay,
so
it's
it's
a
way
of
visualizing
code
snippets
like
this
in
a
tutorial.
A
So
what
we
expect
people
to
do
with
it
is
actually
just
you
know,
start
with
very
simple
visualizations,
for
example,
just
kind
of
initialization
of
a
heap
allocated
string
here
and
and
sort
of
you
can
see
what
happens
is
the
same
thing
we
just
saw.
This
is
not
let
mute
so
the
binding
cannot
be
reassigned,
and
then
you
see
something
happening
with
s
in
this
case.
It's
a
print
line
which
just
kind
of
reads
from
s:
okay
and
then
eventually
it
ends
up
at
the
end
of
the
scope
of
s,
and
we
know.
A
Here
of
s,
s
goes
out
of
scope,
but
we
also
talk
not
just
about
the
scoping
here,
which
is
an
important
concept,
but
also
about
the
the
resource
being
drop
right.
So
because
s
owns
a
resource
at
that
point
and
it
goes
out
of
scope,
the
resource
is
dropped
and
then,
as
we
kind
of
go
through
the
tutorial,
you
see
that
we
start
introducing
more
concepts
like
moves
via.
B
A
A
Is
movement
is
really
like
handing
off
to
something,
and
you
see
that
handoff
happening
in
the
visualization
and
also
at
the
end
here
you
see
that
x
goes
out
of
scope
because
it
doesn't
own
a
resource
at
that
point
because
of
the
move,
no
resources
dropped,
whereas
when
y
goes
out
of
scope
it
no
it
owns
the
resource
at
that
point,
so
the
resources
drop.
So
it's
giving
you
the
information
that
you
know.
A
If
I
asked
you
a
question
about
when
a
resource
is
dropped
or
what
capabilities
x
has
at
a
particular
line
in
this
code.
These
are
the
kinds
of
thoughts
that
you'd
have
to
have.
You'd
have
to
build
this
mental
model
in
your
head
and
we're
trying
to
put
that
in
front
of
you
so
that
hopefully,
as
a
student,
you
can
learn
to
kind
of
generate
these
things
more
quickly
on
your
own
after
some
time.
A
Okay,
so
you
know
so
the
tutorial
goes
on.
I'm
not
going
to
go
through
every
example.
In
the
tutorial
there
is
a
link
I'll
post
it,
maybe
in
the
zulu
up
as
well.
If
people
want
to
play
with
it
for
borrows,
there
are
some
interesting
things
that
start
happening,
so
you
can
see.
A
Of
two
you
know
variables
or
things
of
interest,
there's
the
reference
itself
and
then
there's
the
resource
that
the
reference
refers
to,
and
so
we
indicate
that
by
showing
both
this
reference
s
in
that
function
f
and
we
mark
sort
of
the.
We
indicate
that
the
the
thing
that's
being
referred
to
with
this
d
reference
right
so
star
s
like
what
capabilities
do
you
have
with
star
s
and
then
in
the
visualization,
there's
also
correspondingly
kind
of
two
lines
so
like?
What
can
you
do
through
s
to
star
s?
A
We
can't
mutate
it
because
it's
not
a
mutable
resource,
whereas
here
we're
talking
about
the
the
reference
itself.
So
it's
it's
shared.
We
can
only
read
data
through
it,
okay,
so
we
start
getting
into
a
little
bit
more
of
the
subtleties
related
with
references
here
here,
we're
talking
about
lifetimes
a
little
bit
and
in
a
very
visual
way
as
well.
A
You
can
see
sort
of
what
happens
with
there's
these
borrows
that
happen
to
y
and
z,
and
then
you
know
you
you
pass
y
and
z
over
into
f
and
because
there's
no
further
use
of
the
reference
of
these
two
references,
they're
kind
of
their
lifetime
ends,
and
we
indicate
that,
with
this
return,
sort
of
this
notional
return
of
the
borrowed
resource
back
to
the
original
owner,
and
we
put
a
little
bit
of
work
into
like
making
this
visualization
scale.
A
B
A
Back
to
the
slides,
so
is
this
useful
right?
That's,
I
think
an
important
thing,
an
important
question
to
ask
whenever
you
develop
a
tool.
Is
this
actually
useful?
Are
people
getting
anything
out
of
this
so
the
way
we've
assessed,
that
is
in
my
course,
which
is
upper
level
programming
languages
course
x490
at
michigan.
I've
taught
that
for
four
semesters,
collectively
313
students
have
taken
this
course
so
a
good
sample.
A
These
are
typically
almost
entirely
juniors
and
seniors
undergraduates,
with
two
semesters
of
our
introductory
c
plus
sequence,
and
it's
in
the
second
half
of
my
pl
course.
So.
The
first
half
of
the
course
is
taught
in
ocamel,
there's
kind
of
one
assignment
on
just
intro
to
functional
per
amino
camel
and
then
there's
a
bunch
of
pl
prototyping
that
you
would
expect
from
a
pl
course.
So
people
understand
concepts
like
scope
and
they
have
kind
of
a
more
sophisticated.
Maybe
understanding
of
pl.
A
But
rust
hasn't
been
used
yet,
and
our
introduction
to
rust
is
by
schedule
limited
to
two
lectures,
one
discussion
all
in
one
week
and
then
a
two
week,
long
assignment
roughly
two
week,
long
assignment,
one
component
of
which
is
to
read
and
go
through
that
tutorial
that
I
just
showed
you,
which
we
tell
students,
should
take
between
30
and
45
minutes
and
then
there's
some
assessment
that
I'll
talk
about
in
a
second.
So
you
know
this
is
this:
is
the
particular
educational
context
that
we're
working
in.
A
A
You're
going
to
get
people
with
programming
experience
that
are
interested
in
c
plus
plus
that
have
some
attachment
to
it,
because
it's
performance
and
so
on,
and
so
we
think
this
is.
This
was
a
good
audience
to
test
this
tool
on
for
the
first
time.
So
what
were
our
learning
goals?
Well,
there's
kind
of
two
parts
to
this:
one
ownership
and
one
borrowing.
So
we
want
first
students
to
understand
how
ownership
is
the
foundation
of
memory
management
and
rust
automatic
management
and
rust.
B
A
And
so
there's
some
specific
learning
goals
here
in
terms
of
things
that
we
want
students
to
be
able
to
do
so.
How
do
we
assess
these
learning
goals,
so
this
is
actually.
A
An
important
question,
I
think,
one
that
our
community
should
should
think
through
somewhat
systematically.
So
the
challenge
is
you
want
to
ask
questions
that
assess
their
understanding
of
these?
You
know
invisible
concepts
and
you
want
to
do
it
in
a
way
where
they
can't
just
like
load
up
rust
when
they're
doing
an
assignment
and
and
type
in
the
code
that
we
give
them
and
they
get
the
answer.
So
you
know
it's
not
just.
Is
this
well
typed
right?
So
how
do
we
assess
their
understanding
of
ownership?
A
So
here's
the
kind
of
question
that
we
came
up
with
that,
I
think,
is
a
really
interesting
class
of
questions.
So
what
we
do
is
we
give
them
a
little
snippet
of
rust
code.
You
know
nothing
particularly
interesting
is
going
on
in
this
code,
but
there's
a
bunch
of
moves
and
borrows,
and
things
like
that
that
might
be
going
on
in
it,
and
then
we
ask-
and
you
can
notice-
there's
also
a
bunch
of
print
lines
in
here.
A
That's
just
when
the
string
is
deallocated,
so
you
do
have
to
actually
build
that
mental
model
that
I'm
talking
about
right,
that
we're
trying
to
teach
and
and
model
all
the
moves
and
and
see
when
a
variable
that
owns
that
resource
goes
out
of
scope.
That's
that's
the
that's
the
goal
that
they
understand
that
and
they
can
figure
out
that
the
answer
you
know
in.
A
After
hello
and
before
goodbye,
I
forget
what
the
answer
is,
I
think
that's
it,
so
we
give
them
a.
You
know,
six,
seven,
eight
questions
like
this,
all
relatively
small,
and
you
know
if
people
can
do
this,
that
means
they're
starting
to
develop
an
understanding
of
this
invisible
thing,
that's
going
on
with
ownership
and
moves,
and
we
see
some
success
with
this.
So
the
median
score
on
this
kind
of
question
is
91.
We
also
have
questions
like
this
on
our
final
exam.
A
Also,
very
people
do
very
well
on
that
question
as
well,
and
then
we
also
are
able
to
the
way
we
have
it
set
up.
We
are
able
to
measure
how
long
it
takes
students
to
answer
this
question
when
it's
from
the
time
it's
presented
to
them
to
when
they
kind
of
submit
an
answer,
and
that's
about
five
to
six
minutes
on
on
average
right.
A
So
what
that
means
is
that
students
are
kind
of
like
thinking
through
each
of
the
events,
they're
not
just
kind
of
knee-jerk
answering
based
on
a
quick
assessment
of
the
code.
So
we
think
this
is
promising.
You
know
we
after
a
week
or
two
of
instruction
and
rust
students
are
able
to
understand
automatic
memory
management
where
the
resources
are
being
dropped.
As
a
consequence
of
these
move
events,
the
second
kind
of
set
of
learning
goals
have
to
do
with
borrowing.
A
So
again
they
have
to
understand
immutable
immutable
borrows
they
understand
how
a
lifetime
of
borrow
relates
to
the
lifetime
of
owner
and
then
also
we
want
them
to
understand
the
basics
of
non-lexical
lifetimes
and
rest.
It's
actually
kind
of
a
challenge
relatively
to
assess
understanding
of
borrowing
relative
to
ownership,
because
borrowing
is
really
more
about
restrictions
on
what
you
can't
do,
and
so
you
know
we
can
ask.
We
do
ask
questions
of
the
forum
on
which
line
of
code
does
the
lifetime
of
x
end
and
that's
essentially,
the
sort
of
that
return.
A
Arrow
like
where
should
the
return
arrow
go?
People
do
a
little
bit
worse
on
this,
but
you
know
it's
about
eighty
percent,
or
so
is
the
the
medians
go
on
questions
of
this
sort,
but
you
know
one
one
discussion
topic
that
I
think
I'd
like
to
get
more
feedback
from
the
community
on
is
that
is
there?
Are
there
better
ways
of
assessing
borrowing
and
understanding
of
borrowing?
A
Other
than
also
I
mean
you
can
just
have
them
write
code
and
fight
the
borrower
checker,
but
we
want
kind
of
a
more
targeted
assessment
and
then
one
additional
thing
that
we
did
one
of
these
semesters.
We
did
an
extra
credit
question
where
we
asked
students
to
actually
generate
their
own
rust
business
visualization.
This
is
also
a
nice
segue
for
me
to
talk
about
how
that
is
done.
So
it
is
not
fully
automatic.
What
we've
done
is
we've
developed
a
domain
specific
language.
A
That's
basically
just
a
comment
system
in
you
know
a
formatted
comment
system
in
rust,
so
you
just
take
your
rust
code
that
you
want
to
visualize.
You
annotate
it
with
comments
that
look
like
this
and
you
pass
it
through
our
russvis
visualizer,
and
you
get
this
kind
of
visualization
that
you
saw
so
you
can
see
there's
kind
of
a
column
specification.
What
columns
do
you
want
to
visualize?
A
You
might
not
want
to
visualize
every
variable
and
every
function
and
then
on
each
line,
you
sort
of
say
what
events
happened
on
that
line
in
this
little
comment
here,
and
we
have
this
kind
of
table
saying
what
all
all
the
possibilities
are.
One
thing
I'll
note
here
is
that
this
this
is
a
notional
machine
of
how
rust
works
right.
A
So
it's
not
exactly
a
specification
of
the
rust
borrow
checker,
it's
something
that
corresponds
roughly
to
what
an
introductory
student
understanding,
borrowing
and
moves
would
kind
of
develop,
and
how
do
people
do
on
this?
Median
score
is
100.
This
was
an
extra
credit
question,
so
people
essentially
didn't
submit
it
if
they
didn't
get
it
right.
So.
A
We
should
wrap
up
soon:
okay,
yep,
I'm
I'm
wrapping
up
here,
so
one
out
103,
so
it
took
about
two
hours.
Most
of
that
was
actually
set
up
of
rust
on
their
own
machine
and
things
like
that.
But,
interestingly,
sixty
percent
thought
that
this
exercise
helped
them,
but
better
understand.
Rust
overall
did
russva's
help.
95
percent
of
students
said
it
was
either
help
the
visualization
was
either
helpful
or
very
helpful.
75
percent
of
students
reported
frequently
interacting
with
the
visualization
study.
A
In
our
study
we
also
did
a
small
think
aloud
similar
results,
and
then
the
feedback
was
basically.
I
think
these
things
are
helpful.
I
still
have
to
think
through
the
problems,
and
then
there
was
some
feedback
about
the
actual
mechanics
of
interaction
that
I'll
skip
for
now.
So
to
conclude,
we
think
this
is
a
promising
approach.
What
are
our
next
steps?
One
automatic
visualization
generation
there's
some
challenges
there
with
customizability
and
the
scaling
of
these
things.
Two.
We
want
to
kind
of
explore
alternative,
visualization
style
for
automatic
visualization.
A
Can
you
do
it
without
a
big
sidebar
and
then
finally,
integration
into
more
courses,
public
release
of
kind
of
self-study,
tutorials
and
smaller
learning
modules
for
different
topics?
So
if
you
are
interested
in
that,
if
you
have
a
course
or
you
want
to
develop
material
contact
me,
you
can
play
with
the
material
at
that
url
and
I'll
stop
there.
Thank
you.
B
All
right,
thanks,
cyrus,
fabulous
talk,
we'll
jump
right
into
some
questions
and
then
head
into
the
big
group
discussion.
So,
following
up
on
your
point
about
automatic
generalization,
matthew
did
ask
how
close
to
generating
the
visualizations
automatically
are
we,
since
it
would
be
really
critical
for
playing
with
code?
As
we
talked
about
in
the
last
session
or
in
the
last
talk.
A
Yeah
there's
a
bit
of
automation:
you
can
generate
the
column
headings
automatically
by
just
parsing
out
the
variables
that
are
used
as
kind
of
the
initial
state
and
then
you'll
see.
Actually,
if
you
look
in
this
table
down
here,
there's
this
go
out
of
scope
event,
which
can
be
visualized
in
three
different
ways
depending
on,
if
that
variable
x
owns
a
resource
at
that
time.
So
we
do
track
that
automatically.
You
don't
have
to
decide
if
it
goes
if
the
resource
is
dropped
or
not
the
system
does
that
automatically.
A
So
we've
taken
baby
steps
towards
automating
it,
but
you
know
it's
a
bit
of
a
challenge
to
to
actually
support
the
entire
system
of
the
entire
borrow
checker
of
rust
right.
We
don't
attempt
to
do
that.
We
don't
attempt
to
do
a
certain
advanced
features
that
are
described
in
our
paper.
A
So
I
think
this
is
a
really
interesting
question.
If
you
know,
if
there's
graduate
students
out
there
that
are
interested
in
this
topic,
that's
definitely
a
topic
I
want
to
explore,
but
you
know,
I
think,
there's
some
benefits
to
the
manual
generation
both
for
students.
Doing
a
question
like
this
and
for
instructors
being
able
to
customize
it
and-
and
we
think
it
doesn't
take
that
long
to
generate
it
manually
for
any
particular
example
and
we're
working
on
improving
that
so
yeah.
That's
where
we're
at.
B
One
thing
I'll
just
toss
in
is
I
I
think
one
metaphor
I
find
really
interesting
here
is
thinking
about
this
tool
kind
of
like
dot.
You
know
the
sort
of
format
you
use
to
describe
graphs,
but
this
would
be.
This
is
sort
of
like,
like
a
pro
a
language
of
program,
comprehension
or
visualizing.
Static
semantics
of
programs
is
something
that
there
hasn't
doesn't
really
exist,
but
I
think
if
you
could
sort
of
like,
like
I
really
like
how
it's
extracted
out
as
this
like
visual
language
that
you
could
generate.
B
However,
you
want
and
theoretically
adapt
for
use
cases,
even
beyond
ownership,
potentially
or
visualizing
ownership.
I
think
it'd
be
very
cool
if,
if
it
was
applicable
to
those
sort
of
settings
like
if
you
had
any
any
abstract
interpretation
of
your
program,
if
you
could
apply
it
that
way,
that's.