> My only concern is that lot of the motivating of the ownership
> system seems to be directed at C/C++ programmers, but at the same
> time you're explaining pointers and memory management as almost new concepts.
I think this is a weakenss of this draft, yeah. I want to make it accessible to non-systems people, but also okay for systems people. In the current, actual intro, I treat everything at a high level, looking downard occasionally. This version is more about starting down and looking up, but it might be not enough detail for the non-systems crowd (there's still tons of implicit knowledge here, even though I tried to spell it out) and a bit tedious for the systems crowd (who have intenrnalized much of this already.)Writing is hard.
As [1] says: "Rust for C programmers != Rust for functional programmers."
[1] http://science.raphael.poss.name/rust-for-functional-program...
For example, going through line by line leads to a slew of text that doesn't really provide that much value. I feel you could cut a few paragraphs with a simpler method of explanation with perhaps more code (and explain through comments), visuals (ascii diagrams of the scopes), or something.
I also feel the analogy towards lifetimes relating to segment of lines of code might confuse users.
> Rust knows how to connect the scopes of variables that are pointing to the same thing, as well as how to know the scope of things that are more than just stack-allocated memory.
Too many 'things', knowing Rust I obviously know what you're trying to say but I could imagine it being hard to grok for new comers. However, I don't really have a suggestion on how to explain it better.
After that, you show some code and try to explain it in paragraph form after that. I think it might be easier to just place those explanations inline with the code. That way you can skip the "at line 7, it does this" type of thing.
Referencing the implementation details of the stack and heap, it seems like too many details that are not really needed at that time. Perhaps a difference between the stack vs heap, but which memory address a variable is located doesn't really convey anything useful.
Anyways, I like the where things are headed, but as you said, writing is hard. I've tried writing introductions to lifetimes and ownership and, well, I just gave up. Trying to convey that stuff after you've learned it to people who haven't is hard.
Being one who has "enjoyed" numerous encounters with C pointers (and pointers to pointers, etc.), a lot of the explanation seemed elementary indeed. But I didn't mind the "review", in fact, kind of fun imagining I was a beginner and how amazing it would be to learn the details.
I can see why Rust's concept of ownership is essential to grasp. However, the tutorial was a little murky when it came to the deeper subjects of "mutable borrow" and the cause of the example error.
It took a few readings to get what made the line "let x = &v[0];" so crucial: "...&mut is a promise that there are no other references...", i.e., meaning the promise to "x", since "x" is the recipient (owner?) of the "&mut" of "v".
The final paragraph is the key to the entire exposition, so it would be enormously helpful to take a few extra lines of text to clarify just how the expression "v.push("B");" violates the promise to "x". That's even more vital to your purpose as describing pointers in vivid detail.
People new to Rust are beginners re: ownership, borrowing, et.al., and would benefit from a step-by-step walk through of these less familiar parts.
But I agree it does feel a bit weird to need to explain pointers while also assuming people understand memory layouts. There should probably be a quick guide to memory usage, maybe even using C, and from there introduce Rust's concepts on top. It's certainly a hard problem to introduce a high-level, functional, language that also has very powerful low-level concepts.
Thanks so much Steve for doing this work. Reading the guide made it all click into focus for me when I started, and the rest is _mostly_ syntax.
When you enforce immutability of aliases, as Rust does, aliasing stops being a special case. The underlying value may be the same, but the behaviour is identical to when they are independent.
The only time you have problems thereafter is when you do weird things with the value's address which only coincidentally works. For example, comparing interned strings or Java's Integer objects using == works for other interned strings and small integers, respectively.
I spent the last two weeks reading the entirety of the 30 minute intro, TRPL, and Referecne, and Rust By Example. My background is primarily Python / Java / JavaScript. I can read but am uncomfortable writing C.
This article touches on mutability, references, stack versus heap, ownership, and lifetimes. It has listings of C and C++ code interspersed with Rust. At one point there are nine tables representing memory layout, with no clear indication of what's changed, and only the first 3 tables even fit inside my browser in their entirety.
I understand what you're trying to get to, but I don't think this is that. I'd appreciate detailed sidebars on how Rust avoids dangling pointers / data races / etc., but not part of the main path immediately following "Hello, world." Systems language folks will readily grok that stuff without exposition on what a stack and heap are, while those of us from higher level languages would get stopped in our tracks and completely bogged down in that morass.
Lifetimes and ownership were the most difficult concepts for me to grok, but I was able to make it through TRPL relatively quickly and come out knowing exactly where I was unclear. Rust By Example helped immensely on that front. I specifically appreciated the destroy_box function on http://rustbyexample.com/move.html, though the entire snippet was quite illuminating.
The examples of lifetime elision on http://doc.rust-lang.org/book/ownership.html#examples coupled with the attempts as manually annotating lifetimes in http://rustbyexample.com/lifetime/fn.html finally made that click.
I'm just one learner, but in my experience TRPL is fundamentally sound. I wouldn't fix what isn't broken. It may not sell Rust in the sense of putting its "best foot forward," but it's concise and it works. When shooting for first impressions, it might be worth focusing on the 30 minute intro or some other document instead. I didn't touch TRPL until I had been sufficiently sold on the language from other venues to commit to learning it.
Edit: But holy shit, Steve, thank you so much for the work and care you're putting into this. Rust wouldn't be where it is without you.
Thanks, this was literally my hypothesis for the intro, like qualifying a lead: give enough to get you interested, then either give you more or say good day, depending. Maybe this is just better as the intro itself, or many this draft is at the wrong level of abstraction, we'll see.
I don't know of a succinct overview of Rust for experienced system programmers, and this video certainly isn't that.