Hacker News Reader

Comment by amadvance | Hacker News Reader

Is really rust not needing valgrind, and more specifically the memcheck tool ? OK for leak detection. But is it really able to detect all not initialized memory accesses ?

Anyway, I suppose that rust can still benefit from other valgrind tools, like helgrind, drd, massif and so on.

View on HN

Rust doesn't tend to leak memory, but it doesn't make any firm guarantees about memory leaks as opposed to invalid accesses. For example, even in perfectly safe Rust code, you can make a cycle out of reference-counted smart pointers, and their destructors will never run. So valgrind may be useful for that, and it's common to interact with C libraries which may leak memory. But it's much less common to need than it is in the C/C++ worlds.

I think the parent is saying less that you don't need valgrind, more that you get it for free. I can take a program I'm writing in Rust and run it through valgrind, or other debugging / profiling tools written and designed for c / c++ because the rust binary ends up with the same debugging symbols that a gcc compiled binary could have

Rust still can benefit from Valgrind, especially if you are working on low-level libraries that require unsafe, or interface over the C ffi. The point that I think the parent is trying to make though is that Rust has made pragmatic decisions that allow it to piggyback off existing tools - it's not starting entirely from scratch.

Using uninitialized memory is impossible in safe Rust. There's a standard library function that lets you treat an uninitialized object as if it were initialized, but it's marked unsafe.

Reply on news.ycombinator.com