It definitely feels a little long winded for a person with some background already in systems langauages like C. Do you plan a TLDR for systems language people?
> 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.)
What about two intros? One for the low levelers, one for the high levelers? It's extra work, but it allows to treat more appropriately what each side needs to learn.
As [1] says: "Rust for C programmers != Rust for functional programmers."
I definitely like the approach of starting with ownership, that's definitely a good thing. I feel the current draft places too much emphasis on implementation details of the stack/heap that I'm not sure will help users understand ownership better.
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.
Writing is very hard. Despite the draft's "weaknesses", I thought it was well-written.
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.
A very short TLDR, in my limited opinion, is basically "Take an ML-ish, make sure everything has C-like performance, while prohibiting all memory safety issues and eliminating aliasing". From those basic principles things you can start reasoning a lot about what Rust must do.
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.
Note that Rust doesn't eliminate aliasing, it merely tracks it very precisely. Taking a reference is a trivial way to create an alias, though obviously while the alias is alive you are restricted in what you can do to the referent.
Aliasing is only a problem because they prevent you assuming two values are independent of each other: a write to one could affect the other, if they are aliased.
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.
+1; this feels unhelpfully verbose, and it tries to do too much.
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.
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.
> 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.
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 didn't find this video helpful at all. You have to skip 10 minutes ahead to get to the actual talk. The talk is stunted and, as always with Rust documentation, dwells only on the basics. Audio isn't clear, but neither is the speaking.
I don't know of a succinct overview of Rust for experienced system programmers, and this video certainly isn't that.
Writing is hard.