3 ms·

I haven't finished listening yet; but it should be made clear that Rust claimed to prevent double frees and use-after-free errors but never claimed to prevent m

I haven't finished listening yet; but it should be made clear that Rust claimed to prevent double frees and use-after-free errors but never claimed to prevent memory leaks. Memory leaks were actually decided to be fully safe just before Rust 1.0, and there are multiple safe methods to leak memory. Search for "leakpocalypse" if you want more details. I also spent the day fixing a memory leak in an Angular (JS) project: you can create memory leaks in almost any language, including memory-safe ones (even garbage-collected ones). The tone of the podcast seems needlessly incendiary. EDIT: He actually quotes a part of the doc were they say that "memory leaks are hard but still possible". It's disappointing that Cosmic has leaks; but it's more about Cosmic than the language IMO.

lblume 2y ago
You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accidentally would be an Rc loop, but that is harder to write than Rc::new_cyclic which gives you the memory-correct Weak reference. When you stick to a fully owned tree memory model (or use bump allocators for fancier data structures) things usually turn out very easy, and I pretty much never had to worry about this.
- demurgos 2y ago
  > You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. It's true if you stick to the standard library, but I assume that the Cosmic frameworks adds a layer of complexity. I'm not familiar with their codebase, but I can easily see how an Rc cycle can appear behind a system with lots of shared references (e.g. callbacks, GUI components with backlinks, etc.). You can also get memory leaks through caches without a clear eviction policy. You can also get cases of "memory amplification" where you hold an Rc to a larger struct despite only needing a tiny amount of data from it. Basically, I agree that the standard library tries to steer you away from memory leaks. However, I also understand that it's not foolproof and can see how you can get in a situation with leaks when your approach is to take some tech debt to avoid short-term delays.

lblume 2y ago

You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accidentally would be an Rc loop, but that is harder to write than Rc::new_cyclic which gives you the memory-correct Weak reference. When you stick to a fully owned tree memory model (or use bump allocators for fancier data structures) things usually turn out very easy, and I pretty much never had to worry about this.

demurgos 2y ago
> You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. It's true if you stick to the standard library, but I assume that the Cosmic frameworks adds a layer of complexity. I'm not familiar with their codebase, but I can easily see how an Rc cycle can appear behind a system with lots of shared references (e.g. callbacks, GUI components with backlinks, etc.). You can also get memory leaks through caches without a clear eviction policy. You can also get cases of "memory amplification" where you hold an Rc to a larger struct despite only needing a tiny amount of data from it. Basically, I agree that the standard library tries to steer you away from memory leaks. However, I also understand that it's not foolproof and can see how you can get in a situation with leaks when your approach is to take some tech debt to avoid short-term delays.