alt Hacker News> You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.
If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too
Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays
Replies
I guess parent argues that:
- humans have a track-record of writing memory bugs
- memory-safe languages prevent such by construction
> Memory management bugs is just one class of bugs
It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.
That's why memory bug severity is often "MAY lead to RCE but who knows". At least with non-UB bugs you can reason about them.
In any case, Rust massively helps with logic bugs too. It's not just about memory safety.
Even the statement that (100% safe) Rust does not have memory bugs/mutable aliasing is not always true.
It's well known that Rust has difficulty representing graph-like memory structures, and people have taken to using arrays of `Node`-s to represent graphs, where each graph edge represents a pointer to another node.
This both efficient, and fast, but this approach sidesteps the borrow checker.
If you had a method that 2 mutable `Node` references as parameters, the borrow checker would complain if they'd point to the same struct. If you pass 2 ints, it won't.
Likewise, since liveness is tracked by user logic, you can refer to stale, deallocated `Node`-s or ones that haven't been initialized yet.
I've had people argue this is not a true memory bug, since you're not causing 'real' memory faults, but in C, `malloc` is just a function that hands you pointers into chunks of pre-allocated memory space most of the time, when it doesn't have to ask the OS for more.
I know from experience some people see this criticism as an attack on their favourite language and instantly rebuke it.
But I'd like to argue that there's something there, and it bears thinking about how 'memory allocation exisitng outside Rust' and 'memory allocating existing inside Rust' behave differently might be seen as an interesting dicothomy that needs to be resolved and that resolution might improve Rust's (or some successor language's) memory model.