Ownership chapt can be improved by having problematic examples in C and solutions in Rust

[happy-dude]

• I have searched open and closed issues and pull requests for duplicates, using these search terms:
  • ownership
  • c examples
• I have checked the latest main branch to see if this has already been fixed, in this file:
  • https://github.com/cognitive-engineering-lab/rust-book/blob/main/src/ch04-02-references-and-borrowing.md

URL to the section(s) of the book with this problem: https://rust-book.cs.brown.edu/ch04-02-references-and-borrowing.html

Description of the problem: Hey team, I am really enjoying the brown.edu interactive version of the Rust book. I found the Ownership chapter and sections very informative, especially compared to the verbosity and density in the original.

One thought that my friends and I had while reading this chapter was:

• rust doesn't let you make these mistakes, why are we going out of our way to break rustc features to demonstrate these mistakes? (we can't practice making these mistakes for ourselves)
• we would never write code like these examples, so they seem like a purely academic/intellectual exploration

To help alleviate this, I propose that the chapter can be improved by writing the erroneous / undefined behavior bits in C and demonstrating afterwards how Rust is an improvement.

Suggested fix: By demonstrating the issues in C,

• readers do not have the mental block of reconciling disabling rust-language safety features just to get examples to work or are "impossible" to write in rust
• by being able to copy/type out working errors on their own, readers can better understand how these errors can occur and how they can appear in real-world code
• following the erroneous examples in C with how Rust improves upon that and demonstrates what Rust does better, how the language and tooling makes certain errors and undefined behavior impossible
• this is especially useful for understanding the impact of permissions on variables, where languages such as C has no such guarantees or enforcement of such practice
• makes it clear how "best practices" in other languages are innate and enforced in Rust through the ownership model, borrow checker, and other guarantees

[block0xhash]

1. Best place to practice this is here where you will see what's happening under the hood https://cognitive-engineering-lab.github.io/aquascope/

2. What about those who never coded in C . Will they need to learn C first as a prerequisite or

3. does the book need to teach C and pointers before Rust ?

I actually read that chapter over and over until I got it. I guess this is part of the "experiment". If I didn't get the answer right I assumed I didn't understand and went back and reread.

The metal block you mention I unblocked by actually reading and "dry running" the code and not using the C complier. This helps to burn the understanding in your brain

[happy-dude]

1) aquascope is great; the chapter is already using it to help establish the rules of Rust, but still doesn't address the concerns I raised in the issue description:

• the chapter examples are impossible/nontrivial for the reader to execute themselves
• where it succeeds in demonstrating what is happening, it fails to lay a foundation as to why these rules exist in the first place

2) no, C is not a prerequisite 3) no, because pointers and references are already being introduced in the Ownership chapter

My preference for using C for the bad-practice examples is because:

• many languages (like Rust) share foundational concepts
• the sample code can remain short and concise
• the sample code can successfully be compiled and executed to demonstrate brokenness (which is not easy to do in Rust)
• by emphasizing what can go wrong, it lays a foundation for why pointers and references in Rust are different, where the ownership rules come into play, and how best-practices are innate to the language

You do not have to learn C as a prerequisite to successfully accomplish this.

The metal block you mention I unblocked by actually reading and "dry running" the code and not using the C complier. This helps to burn the understanding in your brain

Re-reading a section multiple times implies that the section was not clear. I argue that instead of gaining a deeper foundational understanding of why the concept is important or necessary, they are instead falling back onto rote memorization of what the language is trying to do.

As an analogy: the reader is learning to wear a helmet when riding a bicycle, but not why the helmet is helpful in the first place.

[willcrichton]

Hi @happy-dude, the short answer is: because we believe it makes you a better Rust programmer. We have done a fair amount of science to justify that claim, described in this paper: https://dl.acm.org/doi/10.1145/3622841

The slightly longer answer: "rust doesn't let you make these mistakes" isn't quite right. A programmer can still make the mistake of writing unsafe (in the sense of violation the borrow checker, not in the sense of using the unsafe keyword) code. It's just that Rust catches this mistake at compile-time rather than run-time. So when you say "we would never write code like these examples", that isn't true! People write code like these examples all the time. When Rust says "this is unsafe", it's then up to the programmer to understand: why is this unsafe? How should I best fix it?

In particular, I added Section 4.3 "Fixing Ownership Errors" to show how thinking in terms of memory safety helps you understand how to fix borrow checker errors. That's the key idea: the deeper understanding helps you know how to respond to the compiler's feedback.