Surprised no one has mentioned another great and similar resource called Rustlings [0] (yes very punny name). You are given some files with todo statements which you'll need to fix and make the code compile and pass all the tests. It's an interactive way to learn which is what got me through learning Rust a few years ago.
The difference is that Rustlings requires the person to already know Rust whereas the link on this post (100 Exercises to Learn Rust) starts teaching Rust from the basics (assuming that the person knows another language).
That doesn't match with my experience: I learned the language from scratch just fine with Rustlings. (In fact, I found it more approachable than the Rust Book.) The first few groups of exercises in it walk you through the basic syntax and semantics, to the point that I found it almost tedious to work through, but I ultimately came to appreciate it.
I did Rustlings without any knowledge of Rust and I thought it worked great. There are links to guide & documentation pages for every exercise. It worked great to learn the basics through practice.
To me "the basics" means either no programming at all, or something rudimentary and half-remembered like you did simple Logo turtle graphic programming in math class as a ten year old and now you're thirty. Not "knows another language".
I think it might be interesting to develop Rust-as-first-language teaching materials, but that's not what this is. Move assignment as your primary assignment semantic, borrowing as your metaphor rather than introducing the confusing idea of "addresses" (in Rust many things we can borrow don't have a meaningful address, but it's fine) and so on.
> I think it might be interesting to develop Rust-as-first-language teaching materials, but that's not what this is. Move assignment as your primary assignment semantic, borrowing as your metaphor rather than introducing the confusing idea of "addresses" (in Rust many things we can borrow don't have a meaningful address, but it's fine) and so on.
I found that when learning Rust, it approximated the mental model that I had already developed for programming. Move semantics and such just felt right. I had used around 10–15 other programming languages by then, but none were even remotely Rust-like.
I don't know why this is. It can't be that Rust is the objectively or even subjectively right way to think about programming. It has to be that its concepts were simply already intuitive to me, but I wonder why that is, when so many people struggle.
Perhaps it's because of neurodivergence, maybe the language just matches the way I think in general and that's why it made sense so quickly. I'd probably make a terrible teacher, because I just do not understand the struggles people have with Rust, and I can't just teach someone to think the same way I do.
Maybe when existing Rust users try to write material for new developers, they write in a way that, for lack of a better way of wording it, is only really accessible to their own neurotype. In other words, it doesn't really help the people that genuinely struggle with Rust's way of thinking, it primarily helps people who already have this way of thinking.
Certainly in regards to say, ownership, Rust has to be very explicit about things which you'll find in the literature make sense for other languages but maybe are barely mentioned when they're taught.
For example the life of objects is something Bjarne Stroustrup's early editions of his C++ book neglect, basically saying yeah objects come into existence and then they're later destroyed and it's only in the third edition once C++ has more powerful techniques for this stuff that suddenly it's important that C++ programmers care about this and there's IIRC a whole chapter of the book.
It is also said that although Rust looks like a semicolon language, like C or Java or something, it's actually not like those semicolon language at all, it's an ML, the syntax makes it more palatable for semicolon programmers to learn and looks more "serious" for a systems language.
As an ML, Rust gets a solid foundation in its type system. Rust has a type with no values, and a type with one value, Sum types and Product types, so we're on firm ground here, we can do type arithmetic. Languages like C++ struggle to have a type with one value†, and can't really do "no values" at all. It's like your system of arithmetic doesn't have zero. You can limp along, the Romans did, but it's an unenviable situation.
† The C++ language isn't really sure how to handle these types properly because its rules say they need at least one byte of storage - but that entire byte is just padding. It's not insurmountable but it's very silly.
Anyway, I think what you're feeling is more real than you've allowed for. This is concretely a better foundation, that's not an illusion. It's not perfect but the sense that this is how things should be makes sense compared to other popular languages.
> Anyway, I think what you're feeling is more real than you've allowed for. This is concretely a better foundation, that's not an illusion. It's not perfect but the sense that this is how things should be makes sense compared to other popular languages.
I know that things like ownership are universal concepts. They are relevant to all languages, even those that don't have a borrow checker. People who do not think of ownership generally do not write good code. They may not be aware of the concept or what it's called, but their thought process contains some implementation of it, even if indirect or limited.
In C, you very often need to know who is responsible for freeing a value, or when it is safe for the one responsible to free it. Someone may think of it in different terms, but the end result is the same. Even in something like Java you still might need to know who is responsible for managing a value.
Because Rust includes these things, teaches us to think about these things, and is generally designed with these things in mind, it is absolutely a better foundation than something like C or C++. A lot of C/C++ software, I'd say most of it, sorely deserves to be rewritten in idiomatic Rust.
But, you know, it's the "right tool for the job" thing. Sometimes Rust isn't the best for a particular application. Just because it's better at what it does, doesn't mean it's also better at what it doesn't do, if that makes any sense.
Of course. I can buy for example that it's hard enough to learn Rust that you wouldn't want to teach say, Chemists to write Rust rather than Python when showing them some Computational Chemistry, even if maybe the ones who "got it" would be better programmers your focus is Chemists, not programmers.
Or on safety we should not write new codecs in general purpose languages, including Rust, because these languages necessarily (Rice's theorem) can not check the semantic constraints we want to deliver safe codecs. We should use WUFFS. WUFFS is also a hard language to learn and as a special purpose language it's not applicable to most problems people have, but it is inherently safe† and delivers extraordinary performance so that's the right choice for this particular work.
† In C++ bounds misses are Undefined Behaviour, likely a security disaster. In Rust bounds misses cause a panic, likely premature program exit. In WUFFS any code which can have a bounds miss isn't valid, you get a compiler diagnostic saying you wrote this wrong, fix it.
In C and C++, Undefined Behavior basically says it's safe for the compiler to assume this hasn't happened, because as a programmer it's your responsibility to ensure it's impossible. This might not have been so bad if completely normal things (such as signed integer overflow) weren't UB. It's not safe to assume the programmer did it correctly, and it never will be. So, these languages have tons of footguns.
UB also exists in Rust, however it's only supposed to exist in unsafe code, and even within unsafe code, you still benefit from Rust's great RAII, move semantics, deterministic destructors, and so on. It's still UB to index past the bounds of a memory region (well... uhh, insert Stacked Borrows or Tree Borrows here, this gets much more complicated, but you get the idea) but you can only do this unchecked from unsafe code, otherwise it'll always be checked and will panic if you attempt an out of bounds access.
When unsafe code is a special delineated section, you're less likely to forget to be very careful.
Although ownership only becomes necessary to think about, once you start mutating data. If you only use immutable data, then there is no need to think about ownership.
[0] https://github.com/rust-lang/rustlings