Are you suggesting that memory leaks don't happen in Rust? Not only has that proven not to be true but the language for some reason seems to define memory leaks as safe behavior.

> based on my experience with Rust

This suggests that you haven't encountered references cycles at your level of experience:

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html...

> Are you suggesting that memory leaks don't happen in Rust?

Their wording was "would be unlikely", rather than "don't happen". The affine(ish) type system, along with lifetimes, makes it so most objects have a single owner, and that owner always knows it is safe to deallocate.

> for some reason seems to define memory leaks as safe behavior

The reason is that Rust aims to prevent undefined behavior, and that is the only thing it defines as unsafe behavior.

Memory leaks cannot cause a program to, for example, start serving credit cards or personal information to an attacker. Their behavior is well defined (maybe over-complicated thanks to Linux's overcommit, but still well defined).

Rust does not protect against DoS attacks in any way. In fact it seems to enjoy DoSing itself quite a lot given how many things panic in the standard library.

whytevuhuni has done a wonderful job of saying the things I meant, clearer than I am able to articulate them. But I just wanted to point out that this is the first sentence of the documentation you linked:

"Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak)."

My sentiment exactly. Rust makes it difficult to accidentally create memory leaks. If you try hard to do it, it's definitely possible. But it's tremendously more difficult to accomplish than in C/C++ where it accidentally happens all the time.

You're seeing memory fragmentation which I would expect not to improve

That's an interesting take about a language that puts variables on the stack by default. The less you put in the heap, the less fragmented it gets. Heap fragmentation also does not account for the ever growing memory footprint of a running instance.

You're aware that C++ and C are also stack allocating by default? Unless you mean something different than what I understand.

C requires malloc (and the heap) for anything that lives beyond the scope of the function lifetime. C++ adds smart pointers and copy/move semantics, but default behavior is still like C, and defaults matter.

Does rust really allow stack allocated objects to escape function lifetime? That seems antithetical to how a stack works.

It's the other way around; Rust is really good at tracking the lifetime of objects, and so Rust code is a lot more reckless with passing around pointers to stack-allocated objects through very long chains of functions, iterators, closures, etc, because it becomes obvious when a mistake was made (it becomes a compile error).

This makes it so that things that appear dangerous in C++ are safe in Rust, so for example instead of defensively allocating std::string to store strings (because who knows what might happen with the original string), Rust can just keep using the equivalent of std::string_view until it becomes obvious that it's no longer possible.

This (avoiding needless copies due to uncertainty of what the callee might do, e.g. caching a reference) makes sense but is not what the grandparent was suggesting.

It's exactly what I was talking about. Rust enables me to avoid using the heap when I would be forced to in C/C++. And thanks to the borrow checker ensuring safety in doing so, this extends to libraries and dependent code in ways not easily achievable in C/C++. The net effect is a profound reduction in heap usage by comparison.