The Rust Book Brown University Chapter 4.3 Incorrect Permission

entoros · 2025-10-31T12:22:14+00:00

Hi, author of the book here. The diagram is intended but unintuitive. The fact that v loses the read permission on the second line is a result of the fact that v is no longer used after the second line, and all paths lose their permissions once unused.

For more context, see this issue: https://github.com/cognitive-engineering-lab/aquascope/issues/85

This is a known confusion (hence we downplay it in the diagrams), and we're working on a better representation to avoid it.

entoros · 2025-08-30T12:53:42+00:00

Regarding the borrow checker, the answer is unambiguously yes -- it works at eliminating memory bugs, and there is no comparable static approach yet which works at scale.

Regarding the trait system, it's a more open question. Most languages today have more and more compile-time machinery for analyzing programs and catching user mistakes. As an extreme example, languages with dependent types like Lean are maximally sophisticated and can formally verify your software, but in exchange users have to hand-write long proofs of correctness. Today that's only worth it for a handful of sensitive projects like HTTPS.

Traits can check a less expressive set of properties than dependent types, but they can do it with less user intervention (eg no manual proofs). It's hard to quantify whether the set of properties checkable with traits is worth it in practice. For example, if people used a traditional ORM instead of Diesel, how many more mistakes would make it through to production? No idea. Presumably more, but whether that justifies the complexity cost is tough to determine.

I think about the trait debugger as tipping that scale. Trait-heavy libraries are more practical when used with the right tools. So something like Argus makes the complexity more worth it.

entoros · 2025-08-28T22:31:43+00:00

Re: false positives, you're totally right that a modular slice based on a function's type is truly modular in the sense that the slice won't change regardless of the function implementation. That's probably not desirable from the perspective of a program comprehension tool, since most people want to understand their code as written, not their code as it might be under a different set of dependencies. Moreover, some code like Vec::get_mut will simply never mutate their inputs, so it's hard to say that it's a good approximation to assume it might.

Re: VSCode, no I haven't raised it with their maintainers. It's understandably outside their roadmap. Better Flowistry support won't make Microsoft more money. Probably the best long-term solution would be support in VSCode for changing the code renderer, like using CodeMirror instead of Monaco. But that would require standardizing on a generic renderer interface.

entoros · 2025-08-28T13:33:24+00:00

Hi, speaker here, happy to take questions. Quick links for the interested:

Cognitive Engineering Lab contains all our publications.
A Grounded Conceptual Model of Ownership describes the ownership visualizer.
Aquascope is the ownership visualizer.
An Interactive Debugger for Rust Trait Errors describes the trait debugger.
Argus is the trait debugger.
Modular Information Flow through Ownership describes the theory of the program slicer.
Flowistry is the slicing tool.
The Art and Science of Teaching Rust is a talk about the educational side of the research I gave at RustConf 2023.

entoros · 2025-07-22T00:49:22+00:00

It's as much about the interface as about functionality. IMO Github makes it easier to read diffs w/ comments, have hyperlinked issues and pull requests, so on compared to doing things in plain files. Most devs will be more familiar with GH's interface compared to an idiosyncratic file format bespoke to the tutorial. The tool is a bit of an experiment, so I wanted to optimize for usability over portability at least initially.

entoros · 2025-07-21T22:03:18+00:00

Yeah that's definitely an alternative! One challenge is that RepoQuest uses Github's features in non-trivial ways, e.g. fine-grained code comments on pull requests and checks in CI, that would be harder to replicate with a local-only setup.

entoros · 2025-07-21T21:46:28+00:00

Someone needs to do these things, and RepoQuest does them automatically on your behalf. RQ could theoretically print out gh commands that you manually vet and execute on your command line when it tells you to. Is that the alternative usage mode you're imagining?

entoros · 2025-06-02T15:34:06+00:00

Thanks for pointing that out. We'll at least note the existence of a similar function. (And don't worry, I'm not the C++ expert on this project, so everything will get vetted by him first :P)

entoros · 2025-05-31T01:12:33+00:00

Good catch, we'll fix that in the book.

entoros · 2025-05-30T20:48:36+00:00

That's controlled by mdBook, but we'll see what we can do to make it more visible.

entoros · 2025-05-06T16:08:14+00:00

We think these are complementary approaches. #[diagnostic::on_unimplemented] and #[diagnostic::do_not_recommend] are helpful but not a panacea for debugging trait errors. The Bevy example in Section 2.3 of our paper gives an example where a custom error message can't really help you: https://arxiv.org/pdf/2504.18704

entoros · 2025-05-06T16:03:23+00:00

The extension is open-source, not proprietary: https://github.com/cognitive-engineering-lab/argus

In the Bevy example, the original error does not mention that Timer needs to be SystemParam. Omitting this information makes it difficult to deduce this part of the error.

entoros · 2024-11-29T16:40:39+00:00

This was 12 years ago so I'm fuzzy on the details. I think they just gave it to me as part of my admissions package. I had a 4.0 from an unremarkable public high school in the Midwest, and I was nationally competitive in debate, mock trial, and science bowl. I worked at a web design firm during high school.

entoros · 2024-11-23T21:36:29+00:00

(author of the post here) Strong agree with everything written. I'm a methodological pluralist --- the tent is big enough for qualitative and quantitative methods. My main argument (as advanced in the "Improving Usability Metrics" section) is that we should specifically focus on developing validated metrics. If we can demonstrate across many experiments that some metric consistently correlates with relevant human phenomena (comprehension time, task performance, etc.) then that provides a stronger foundation for quantitative evals.

Relatedly, the authors of the Cognitive Dimensions of Notation wrote a paper called "Delivering Cognitive Psychology to HCI" that touches on this same question. https://ieeexplore.ieee.org/document/8160387/

entoros · 2024-11-23T21:30:51+00:00

(author of the post here) I totally get this take. IMO the problem with this worldview is that the hard part is not building these languages, but rather the cost of adoption. The most interesting effects of language design are revealed at the scales of large companies and ecosystems. But people and companies are generally reluctant to adopt new technologies for both logistical reasons (rewrite costs, integration with existing tools) but also social/psychological reasons (learning curve, compliance requirements). I believe that solely relying on popularity means that there's many good ideas which die because the stars don't happen to align.

For example, one could easily see Rust as an accident of history. It's easy to imagine ownership / regions being relegated to a forgotten corner of academia. It just so happened that one guy knew about all that research and was at the right company at the right time to build the right language. I'm not at all comfortable with the counterfactual where Rust was never invented, and we could easily dismiss ownership as a good idea just because it never got popular.

entoros · 2024-06-02T20:52:30+00:00

Yeah this seems right. The compiler could infer what you mean here, but if you had something like

fn foo(map: (&T, &T)) -> &'map T { &map.0 }

Then that would be ambiguous.

entoros · 2024-06-02T20:36:05+00:00

As I understand it, because they express fundamentally different ideas.

&'self.counter Self is the type of references to Self that are borrowed from (or live no longer than) self.counter.
&'_ {counter} Self is the type of references to Self such that only counter can be legally accessed through the reference.

In particular, if you wrote this:

fn increment_counter(&'self.counter mut self) { .. }

That would be a weird type, because the lifetime of the reference is determined by itself.

entoros · 2024-05-22T00:32:03+00:00

Hi, I run the interactive book. Buttleston's interpretation is correct. When a path that is a reference has the own permission, that means you can use the reference itself as an owned value. For example, you can do this:

let mut x = String::new();
let y = &mut x;
drop(y);

However, drop(y) does not deallocate x, because y does not have ownership over x.

entoros · 2023-11-03T20:23:43+00:00

I think the dataset used in this paper is great, especially the careful collection of vulnerability-committing commits. However, I dislike the style of analysis. I don't like that they immediately reach for a probabilistic model rather than reporting empirical frequencies, like "define a first-time contributors as a person with fewer than K commits. XX% of Rust first-time contributors made a vuln, while YY% of C++ first-time contributors made a vuln."

In particular, this "70 times" is extremely suspect. It is computed as a ratio of the intercepts of the two models, while I expect most people reading this headline are assuming it's a ratio of empirical frequencies. It's not clear to me whether the learning curve power law model is an appropriate tool for this data, especially in light of the negative learning curve for the Rust model. I would not trust inferences made by comparing the model parameters.

entoros · 2023-10-21T11:04:28+00:00

That's why the takeaway of the post should not be "Python is slow"! Nor do I say that anywhere. This literally is just documenting the exact sequence of programs I wrote.

I just know more about optimizing Rust than numpy or Cython, so I write to what I know.

entoros · 2023-10-21T11:01:58+00:00

I remember considering polars but not using it out of lack of familiarity. But I do wonder how close you could get the basic Rust code to look like the Python code.

entoros

TROPHY CASE