RustEdu Workshop 2022 - RustViz: Interactively Visualizing Ownership and Borrowing

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.

[KohuGaly]

It would be nice to see how control group (ie. one that was not thought through this visualization tool) performs in the test. The "students score 91% with this tool" doesn't really mean anything if we don't know how they perform without it. Does the tool improve their performance? Does it reduce the time they need to learn the concepts? Does it simplify the teacher's workflow? We don't know.

[zzfkbcu]

The answer (for 13:45) is after goodbye because the string is moved into the id function and back out. Println than takes an implicit reference and the string is dropped at the end of the function f.

[DavidSchmitt]

Now I want that in my vscode: select a thing, get its lifetime graphed out on top of the source.

[affegpus]

I always found easier to think of scopes owning the data, not variables.

[ClearerThanMud]

Toward the end you say that you don't handle the full semantics of the borrow checker. If that's because the semantics are hard to derive from the code (rather than hard to display), would it make sense to give Polonius the ability to generate a file detailing the ownership details for a body of code, and just have the visualizer generate its display from that?

[finnmonstar]

Impressive! Thanks for the awesome content.

[dragonmax]

This is really cool. Would love to use this to explain Lagos in rust.

[sergesolkatt]

I'd wanna write a CLion integration for this

[MrYevelnad]

What really help me understand ownership is by playing with struct.
struct Foo{
foo: i32
}
impl Foo{
fn add_to_foo(mut self, add: i32) -> Self{
self.foo = self.foo + add;
self}
In main we got a code like this
let mut foo = Foo{foo:1};
foo.add_to_foo(1);
println("{}", foo.foo);
This would return an error because the second line has already had the ownership of the foo we created. Just think that everytime we use the simecolon, that line that uses foo will become the owner. To fix this probl we can put the let keyword
let second_foo = foo.add_to_foo(1);
println! ("{}", second_foo.foo);
remember that our method add_to_foo() returns a self. But what if we add foo again? Then we just use the let again and again. But what if we have a multiple methods on a single struct? That would be a cumbersome to use let again and again. So & exist because we are lazy. just buy puting & before mut self
fn add_to_foo(&mut self, ...)->&Self{

self
}
In the main function we can just do
let mut foo = Foo{foo:1};
and do
foo.add_to_foo(1);
println!("{}", foo.foo);
foo.add_to_foo(1);
println!("{}", foo.foo);
Over and over again. & Is like a contract that foo.add_to_foo(1); signed with let mut foo = .... that he will return what he has borrowed after semicolon.