f 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)?

Overall it’s from having gone through [most of] a Computer Science and Applied Math engineering course. Some of the courses:

• functional programming with OCaml
• proving correctness in simple programs
• Computer Architecture 101 that walked us from building simple logic gates out of transistors to simulating a 32-bit processor on an FPGA
• implementing some common collections, like Rust’s Vec or a linked list, in C
• parsing and regular grammars
• intro to compilers

This 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).

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.

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.

I was reading this last evening and ultimately decide against pinging you with it at the time, lol.

It directly riffs off of, and complements, the article you posted. It also speaks to your remarks on an optional garbage collector, as well as “how to think about the lifetime/borrow checker/permissions interplay”.

but I think I would have found it better to go from the basic idea of pointers as a way of not taking ownership

small quibble: String, Box, and Vec are all technically pointers that do take ownership (rather, they have ownership of what they’re pointing to). It’s really only “references” in Rust that don’t take ownership. Which, IIRC, is more or less how The Book introduces references in chap 4. So I’m not really sure how what you’re describing would differ from the current state of the book. Nonetheless, I understand the confusion that comes from “learning about” lifetimes so “late”.

I suspect Rust is so complex, and like a living organism its parts have co-evolved together so much, that there is no linear explanation or introduction that can “truly” do it justice. You sort of have to throw yourself in, and repeat that process from a handful of directions/trajectories, to start to get a cohesive idea of the whole. I say “co-evolved” notably because so much of “modern” Rust seems to me to be syntactic sugar over “core/original/2015” rust.

I haven’t gotten to the chapters on explicit lifetime annotation this time around, but I expect The Book to clearly state, then, that everything has a lifetime and the compiler actually infers most of them for you as part of this “syntactic sugar”.