"How Rust manages memory using ownership and borrowing" blog post contains numerous errors

I am a Rust subject matter expert, and I would like to further substantiate the erratic nature of the blog with a few more issues I encountered.

The computer memory allocated to running programs is divided into the stack and the heap.

[...]

Rust handles memory efficiently by storing literals (integers, booleans, etc) on the stack.

Even if we discard the conflation between a literal and a primitive piece of memory, it seems to disregard that a process contains more memory segments than just stack and heap, and that something like the string below could reside in a static, read-only memory segment.

static DERP: &str = "Imma static string hurr durr";

In any case, the Rust Programming Language book provides more solid definitions of stack and heap.

If a variable is assigned to a new owner, then the original value gets dropped, as it would now have two owners.

That is inaccurate. The compiler does have the concept of moving a resource, so a typical assignment would not "drop" the original value. At best, it would invalidate that variable for further use.

let x = String::from("wat");
let y = x; // moved, no memory allocation or freeing takes place

It is not that the author is oblivious of the concept of moving a resource either, as that is further explained some sections later. It is possible that another conflation took place between variable bindings and values.

To allow programs to reuse code, Rust offers the concept of borrowing, which is similar to pointers.

OK, I may be picky here, but saying that "borrowing is similar to pointers" is a severe undermining of the borrowing system. If the target audience intended was the overall developer base, portraying borrowing as "creating references with extra guarantees", or even just as "similar to references", would have been much better.

fn list_vectors(vec: &Vec<i32>) {
    for element in vec {
        println!("{}", element);
    }
}

This signature does not follow idiomatic guidelines for passing sequential data to a function, something which anyone sufficiently experienced in Rust would know. The signature below is simpler and works for even more types of inputs.

fn list_vectors(vec: &[i32]) {
    for element in vec {
        println!("{}", element);
    }
}

(not to mention that list_vectors is a poor name for printing each element of a single vector)

The subsequent example of mutable borrowing:

fn add_element(vec: &mut Vec<i32>) -> &mut Vec<i32> {
    vec.push(4);

    return vec
}

...just makes no sense at all! It does not make it clear that a mutable borrow already "returns" the value back to the owner, even if you do not return it again. It passes along a mutable reference to the caller when there is hardly a need for that.

A proper, idiomatic way of writing this function and explaining mutable borrowing would be:

fn add_element(vec: &mut Vec<i32>) {
    vec.push(4);
}

And with this you would be able to write this:

let mut my_vec = vec![1,2,3];
add_element(&mut my_vec);
println!("my vec: {:?}", my_vec); // prints [1, 2, 3, 4]

Copying duplicates values by copying bits.

Has the post been subjected to any kind of proof-reading?

If everything was perfect with Rust’s borrow checker, other systems programming languages might switch or offer releases with an implementation of a borrow checker. On the subject of memory management, it’s a trade-off between user experience and convenience.

These sentences leave the impression that borrow checking is a feature that a language development team could add on top of most systems programming languages if they just wanted to, which is very misguided. Even the latest efforts in C++ to better diagnose resource misuses (namely the Lifetime profile specification) cannot go as deep as Rust goes, because that would have required a non-backwards-compatible overhaul of the type system.

And this section continues with other phrases which are either vague, unclear, or just downright misleading.

As program size grows, it may be difficult to self-ensure the ownership rules, and making changes may be expensive.

I would be surprised if there was a strong correlation between code size and difficulty in satisfying the borrow checker. These difficulties emerge as you try to express more complex data structures and algorithms, not exactly when the program size increases. Further down the same section, it becomes clear that the author meant something else when saying "as program size grows":

Many developers, from beginners to experts, get ownership errors from the borrow checker, with more errors coming from implementing complex data structures and algorithms in Rust.

"Expensive" could also mean a lot of things, but most of the time the only potential cost is in compilation times, unless the recourse was to clone many values around or encapsulate values in reference-counted primitives. Maybe I'd let it pass.

While the Rust compiler prevents mistakes like dangling references by performing checks, Rust also provides an unsafe keyword for developers to leave the block unchecked.

This is one of the biggest misleading sentences about Rust that you can find out there, and it's appalling that Stack Overflow is contributing to this misconception. Let's be clear here: The unsafe keyword does not disable nor relax the borrow checker. Rather, it lets the developer do things that the compiler cannot ensure that are safe.

It may seem subtle, but it makes a huge difference. Wrapping a piece of code around unsafe does not suddenly make it ignore borrow checking. Rather, it lets the developer do, among other things, the dereferencing of raw pointers. As raw pointers are more akin to pointers in C, they hold no lifetime information, nor do they guarantee that they actually point to something valid.

This could be detrimental to code security if external dependencies use the unsafe keyword.

I too find this phrase confusing. What I can say is that each unsafe block could indeed be an open door to memory-related vulnerabilities. When projects depend on unsafe, developers are advised to carefully document each occurrence explaining how the necessary conditions for safety are fulfilled. Libraries depending on unsafe may typically include other forms of testing to detect misuses (such as running tests on an interpreter, or with memory sanitizers). Still, most projects do not need unsafe, and its use is preferably kept reserved to places where it is absolutely needed. My biggest Rust project, comprising 16 crates over 30k lines of code, uses no unsafe blocks directly.

Not sure if this changes the overall interpretation of the sentence. I still consider the poor wording of the previous sentence about unsafe a much greater peeve.

All of this to say that the folks at Stack Exchange Inc should probably take better care when looking for writers for their blog, as well as when reviewing the content for both technical accuracy and readability. We can't downvote these blog posts, which makes things worse.

In this case, I wonder if you had just considered inviting Jake Goulding for another blog post on the subject, whose knowledge on the topic is quite well proven.