Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> This approach to memory management is completely at odds with the whole point of Rust.

No, not in the slightest. Rust works extremely well with arenas.

> In fact, it creates all sorts of problems. First, and most obviously, it's really hard to keep track of all those allocations, so you get leaks, and use after free, and all the other familiar memory bugs.

Given that the context of this subthread is Rust, I'm not sure why you bring this up. Rust doesn't exhibit any of these.

> But you also get bloated memory use, with both your user code, and the allocator having to keep track of all those chunks of memory.

No, Rust often uses less heap memory than the comparable C or C++ program, because it's so much easier to safely pass around pointers to the stack and thereby avoid the need to use the heap at all. Defensive copying isn't a thing in Rust.

> You incur often ridiculous CPU overhead constructing and tearing down these massive, intricate structures.

No, there is no ridiculous CPU overhead here. Most objects in Rust have trivial drop implementations and simply recursively free their children, who also have trivial drop implementations. Freeing memory does not show up on the list of performance bottlenecks for any ordinary Rust program.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: