When I recap the rust programming book, I find that the introduction of ownership and borrowing mechanism are all explained by specific computer or memory structure. But i think its wrong to assume the learners have the base of c-like programming experience, and it makes rust unsuitable to be the first programming language to learn.
The ownership and borrowing indeed could associate to real world
. I wonder could we explain the core part of rust without looking into the implementation details?
Yes, this has been discussed quite a lot and many people agree with you. However, to improve the book takes work, and I don't think there are a lot of people working on it right now.
I think would be a disservice to those who do know programming languages before Rust. This is a balance to strike here. Perhaps there could be hidden by default or hidable sections that could explain the terminology you find confusing in more detail?
I suggest reading this very recent, related discussion. There is a lot of disagreement about what you need to know in order to learn Rust.
Sometimes i think knowledge is the burden. For begginers without knowing c-like programming laguage, ownership might be easily to accept(i dont know). But for c-like programmers, it seems that they would strugle on this concept, as they think some address "owns" something.
The current state of the book is servicing to those clike people, build the ownership from concrete address to abstract variable. While its really strange for beginners or gc-like programmers to first know details of memory than telling them its unnessary for you to manage in rust.
Maybe the start goal of rust is to mitigate memory security problem in c and cpp. But I really believe its unnecessary to explain how we mitigate this in the book.
Well maybe we need another book for gc-like and beginners. And mark the book as for c-like programmers.
In the discussion that I linked, people say just the opposite: that the book was written for non-C programmers, and that the section on heap and stack memory is out of place there. I suggest ignoring that section, if it causes confusion.
When I myself learned Rust a few years ago I found the book well written and logical, if at times a bit slow to get to the point (I already knew what a heap and stack is, etc). My background is in C++ (professionally) but I also knew some other languages such as Erlang and Python (and a tiny bit of Haskell).
I believe C/C++ is a very important audience for Rust, as Rust is a systems level language that is trying to replace C and C++. That Rust is also amazing at many other domains is a great bonus, but it would be a bad idea to alienate the C++ crowd: humanity needs a memory safe replacement for C and C++ to make our digital infrastructure safe and secure. We want that transition from unsafe to safe languages to be as easy as possible.
All that said, I'm in no way opposed to making the book more approachable, but it shouldn't be about improving it for one group to the detriment for another group. And having either two books or two versions of certain chapters might be the best option here.
You are right. For current state of the book, the problem is Understanding Ownership - The Rust Programming Language explains too "detailed".
Even if the "stack vs. heap" portions aren't completely hidden, they should be complemented and not the only thing emphasized by that chapter, IMNSHO. For example, the book introduces the Copy trait in a section titled "Stack-Only Data". This is very misleading! Copy is about destructors, i.e. resource management.[1] Data structures can be fully contained on the stack and manage resources (Ref<'_, _>, File[2]). Data structures can refer to the heap and be Copy, too (non-owning pointers, including references to leaked data stored on the heap).
(My phrasing there -- fully contained on the stack -- is actually a mirror of another aspect of that chapter which should be cleaned up. Fields are inline, not "on the stack". E.g. you can put a String in a Box<String> and the pointer-length-capacity triple is no longer on the stack.)
Every or almost every borrow checker example is based around dangling pointers and stack vs. heap.[3] Other examples should be presented (like how double-closing a File is avoided), and the fact that aliasing a &mut _ is in and of itself UB should be emphasized (i.e. &mut _ are exclusive[4]).
I don't think the stack and heap portion needs to be totally removed, but it could be simplified (in addition to being complemented). For non-system programmers, it could be presented as when resources are released (e.g. unmoved variable resources are recursively released at the end of scope, including the end of a function). For system programmers, enough terminology ("heap" for runtime allocated memory, mainly) could be maintained that they can follow along with their pre-existing knowledge.
I agree with you. Stack and Heap should be re-defintion without concrete computer or memory structure. They are some type of resource.
But I even though believe stack and heap are unnessary to introduce. For copy trait, it could be abstract that the type with copy trait could be easily gotten and copied in computer world. And that explanation seems to be enough. No stack no heap, where they are doesnot matter.
Have you already took a look into my book? I tried to avoid too much verbosity and explanations that are unnecessary to learn the Rust language. I only assume that the reader is familiar with the most basic concepts of system programming. The title "Rust for C-Programmers" might be a bit misleading, actual C knowledge is not necessary to read the book. "Rust for Polyglots", "Rust for Adults" or "Rust as your next Language" have been suggested as alternative titles 
While some people label the official books as "excellent", I think that the book from Brown University has a bit too much low level information, which makes learning too slow for the beginning. The original book has some verbosity, but I think for absolute beginners this might be helpful, and reading it one time should be no problem. Reading parts a second time can be boring.
[EDIT]
I really wonder why some people think that the official books have too much references to the C language. As far as I remember, there are only very few in both books. Just some aspects of systems programming is explained. And actually I think, learning and using Rust without knowing the most basic fundamentals of systems programming makes not much sense. I can remember some people came from Python to Nim some years ago, just because NIm looks similar to Python. And then tried Nim, expecting a big performance increase, but got disappointed. When you know only the language itself, you might use a lot unnecessary or slow operations, like unneeded allocations, or using the wrong data structures. For example, in Python it makes no big difference, if you use a hash map a lot, because the language is slow by design. For system languages, unneeded allocations, or the unnecessary use of slower data structures like hash maps, or insert operations in vectors causing shifting of all the elements, could easily destroy the performance advantages of systems languages.
So my conclusion is, that for absolute beginners it can never be really easy and fast to learn a complex systems programming language like Rust. Even with Nim a few had problems, and people switching from Ruby to Crystal had similar problems. Of course you can read as a absolute beginner some of the tiny Rust books at Amazon, often with less than 300 pages. Or the "Rust in a months of lunches". But that does not help you to become a real Rust systems programmer. For these people I always recommend to better use something like Python. If you don't believe me, perhaps have a look at Introduction - Fast Track to Rust. I think that author had good intentions, and it is freely available. But those 135 pages can touch only the surface of Rust programming.
Frankly, my own belief is that it have to be inverted. If you learn about ownership and borrow from layman examples (my favorite is textbook[1]/workbook[2] approach) and then go to the idea that “function own variables that are declared inside” then stack automatically arises as a chain of “suspended”, “quiescent” functions – and heap complements that view by adding idea that some information may not, naturally, belong to any one function but have to exist “somewhere else”.
In safe world of rust, i think there is always a variable owns something. No matter with stack or heap or anythings else. Then its no need to introduce them in the rust book.
You can use Rust without knowing something about stack and heap. Just imagine that each owned variable is stored somewhere in an abstract way. But on the other hand, introducing stack and heap is possible on less than 3 pages in a book, and is easy to understand, easier than other Rust concepts. Would you prefer to never learn about stack and heap? Or just later?
You still need to introduce them, or else it's unclear why Box<…> exists and what it does.
But it's easier to go from ownership and borrow to stack and heap for a newbie then in the opposite direction.
One may imagine an alternate Rust where VLAs not even exist, but may change size, dynamically.
But Rust, as it exists today, is not designed like that. Structures with unknown, growable, size have to live on heap.
Maybe because they(include me) see the power of the type system in rust? we know rust is a system level programming language. its much securer than c or cpp as we believe.
But if we look into the safe world of rust, i think the most important things rust earns safety and efficiency is that the notion ownability abstracts the real world and computer world. We could do a lot of things even without knowing specific structure of a type. It's really important and useful. If you can not manage the specific memory, then no memory security issues. Ownership of specific variable is the core part to make something efficient than gc.
I think rust does have chance to be more popular if we somewhat hide them because its really unnessary.
I know it. But you even can think its just a container. Not a heap or where they are. You could think its magically type that someone built something for you.
The type should hide this, and box type really hide it.
I think we should not see Rust too much as the "one and only best language" ever. Languages with a GC are mostly safe as well, at least statically typed compiled once like Go or Nim, and some more. Swift might be an alternative of a Rust for which we do not have to know so much low level stuff. For a lot of tasks we do not really need a systems programming language, and often a GC is just fine.
Yes.
No. They are surprisingly, unreasonably, crazy hard for the vast percentage of population. No one really knows why.
Most people would never learn. It's not about “stack” and “heap”, really. It's about what Joel calls “pointer arithmetic” and describes like this:
I'm not quite ready to join him on the people seem to be born without the part of the brain that understands pointers (because I remember how much I struggled with them in middle school, when I first read about them – yet after many years it's easy for me to work with them…[1]), but I would still say that explanation of ownership and borrow with the use of pointers, stack and heap is unnecessarily cruel to these people who have trouble understanding pointers.
Even if not easy to always find bugs in algorithms based on them. ↩︎
Sure… but that “magic” need to have a name to distinguish it from other types of “magic”. Why not call it “heap”, then?
You don't necessarily need to know how it works, just need to know that something can be placed on heap and removed from heap – and Box/Rc/Arc are doing that for you.