A nice comment in a forum thread (extracted below, but also see the shorter more facetious version below that) about references and their lifetimes in structs. Here is a link to the full thread over on users.rust-lang.org
I feel like I needed to hear or read this, and I feel like this sort of clarification is not put front and centre enough in rust learning material (as others in the thread say too). “The Book” certainly doesn’t seem interested in clarifying perspectives like this.
The Comment
Other languages use term “reference” for storing things “by reference” or just referencing any object anywhere in general. It’s not like that in Rust.
What Rust calls “reference” is a much more specific thing, that is no so general-purpose. It has a narrower, restrictive usage. Rust references are more like read-only or write-exclusive locks. They make their target unmovable and immutable for entire duration of their existence. They can’t exist on their own, only as a counterpart of an owned value.
References in structs also make the whole struct itself temporary, and everything that touches that struct becomes temporary and tied to the scope of the borrowed value that started it.
If these restrictions (that cause you fight with the borrow checker) aren’t what you want to achieve, then you don’t want temporary references.
99% of the time when you need to store something “by reference”, Box (or Arc or String or PathBuf or Vec or some other owned type) is the right answer.
Note that and Box<T> have identical representation in memory — a pointer. They differ by ownership.
In Short
From here
You’re not allowed to use references in structs until you think Rust is easy. They’re the evil-hardmode of Rust that will ruin your day.
😉
Use Box or Arc to store things in structs “by reference”. Temporary borrows don’t do what you think they do.
I finally clicked over to the thread, and you’re totally correct; the author is clearly talking about their collective encounters with newcomers rather than their own rust “journey”.
This makes me want to share a growing hunch of mine: rust is, currently, made by and for someone like me, who’s had the privilege of developing a (rudimentary) working knowledge of the fundamentals involved in how today’s computers work, from the physics involved all the way up to something like OCaml or python, before ever hearing about Rust itself.
More specifically, there’s so much that The Book leaves assumed-yet-unsaid, even when it really tries to provide background and rationale for concepts.
I don’t think it’s reasonable to expect [The Book’s writing team] to properly teach everything that it later relies on, and it already does say that it expects a certain level of programming experience from the reader near its very beginning. I think it could use a more explicit and concrete list of “requirements”, though, like a dependency tree of prior concepts to acquire. Maybe that could help it strike a better balance between over- and under-explaining things.
Generally agreed. Awesome to hear that you’re gelling with the language! If I may ask, what particular experience or background knowledge do you think makes you and rust such a good fit? Knowing OCaml (I’ve certainly heard of OCaml as an adjacent language to rust in terms of concepts and interests)?
Yea, agreed. In general my policy is that a text book or monographs has the task of mapping as many prior backgrounds to new understandings as possible. This often requires constructing non-linear content and guides to navigating it but can often be worth while IMO.
In relation to rust, it seems to me that it’s the sort of thing that benefits from openly engaging in directionless “horizontal” learning in order to build up a necessary foundation for then building “vertically” once enough pieces are in place. At least more so than more basic languages.
A “steep” learning curve, IMO, is often confused for this sort of thing, where in reality you’re not learning difficult or “steep” things sequentially, but meandering confusedly around a space non-linearly until things finally “click” (ie, until the foundation is sufficiently formed). The thing is that openly embracing a structure that isn’t always building “upward” can make the “journey” feel much less steep than it is.
I used to run a workshop on git for non-CS academic researchers and I opened with a warning that it was going to be structured like climbing a spiral, starting with the problems it solves, then basic ideas, then how those ideas can solve the problems, then a demonstration of each followed by painting a complete picture of how git would fit into one’s workflows. And I found it worked well. People often found it boring at first, but really appreciated it once things started clicking and had fewer confusions I think than if things were done differently.
Overall it’s from having gone through [most of] a Computer Science and Applied Math engineering course. Some of the courses:
Vecor a linked list, in CThis gave me an appreciation for many of the things that Rust forces you to confront head-on like stack vs heap and why stack frames are created & dropped, copy vs clone vs move, types sometimes needing to have sizes known at compile-time, and of course all the use-after-free, double-free, etc shenanigans that come from pointers.
Edit: and getting pretty familiar with Python as my primary language (which had nothing to do with attending engineering school). Rust’s traits, and the way that many of the “higher-level” language features are directly implemented using canonical traits, is very similar in practice with how Python uses “dunder” methods (=“double-underscore”, of the form
__methodname__()) to duck-type its language features like iterators, collection length, collection indexing, dot notation access/manipulation, context managers, and even inheritance. Context managers in particular are almost equivalent to how Rust drops things that exit scope (they allow you to attach behavior to exiting scope in an otherwise runtime garbage-collected + interpreted language).I would describe OCaml as if Rust had been invented from a pure maths point of view of computation, as opposed to how in reality Rust was invented from a “when can [heap] memory be predicted by the compiler to be free-able” (my own words, obviously). So you can do things like specify a “true” generic function in OCaml that infers the restrictions that apply to the valid types it can receive, and the compiler takes care of mono-morphizing that code for the various types that your program actually ends up manipulating/passing to that function at runtime. All functions are partial and composable, and to mutate things you have to explicitly delineate a block of imperative code (everything is immutable + functional by default). You end up doing a lot of pattern matching. Many problems can be compactly solved by recursively pattern matching over arrays and tuples while shuffling around the data that you’re working on (aka dynamic programming).
Yes. I made the analogy to biological organisms in my other reply, but you could also make one with human societies; you can’t understand a society by starting from any single member and slowly zooming out. You’ll need to at least repeat that process from multiple different starting points before you begin to form any true/deep understanding of that society as a whole. I.E., you need to examine the garbage collectors and the town priests and the brothel workers, not just the landowners or the factory workers.
I really like that “climbing a spiral” pitch! I wonder how adaptable it would be to learning Rust, however. Or rather, how one could construct said spiral differently; it already feels like The Book spirals upward and outward from a core of general/abstracted programming.
Thanks for the reply! Also nice curriculum there. I haven’t done most of that (or not enough) but I’ve basically written up that as a list of shit I should have under my belt … so nice for me to see personally too.
Yea maybe. For me, and I’d imagine many who’ve read The Book, a more Spiral-ish or biological/horizontal learning approach on references/pointers etc would go far I think. I haven’t searched hard for it, but from about mid-way through Ch4 I’ve thought that a good deep dive on working with the borrow checker would go far. Given the blog posts and forum threads we’ve linked to here, it almost feels like there’s a hole in the available material. It could work a bit like a reference too so long as it has a good amount of examples well organised along conceptual grounds, which I think it should. But if it addressed all the required concepts and then dug into good examples, both trivial and realistic/applied and mapped the relevant problems and solutions back to all the concepts and their treatment elsewhere in the book, while also providing reading guides for people of differing backgrounds … I think it could go quite far. Maybe you’d be just the person? 😉
You’re welcome!
I strongly agree with the feeling that there is a hole in the current material. At the same time, given the glimpses I’ve had of the other chapters and their sections, I wonder if we “just” need to get through the rest of the book.
The current state of The Book and our progress through it as a community specifically reminds me of being at school: the lessons build on each other, and it always takes a certain amount of material covered before you start to really make sense of things and “refactor”, almost, your prior understanding.