3 ms·
I'm glad Rust is working well for them. Everyone should use tools they love. That said, you can write an inaccessible reference cycle that never calls drop() i
by hansvm 2y ago
I'm glad Rust is working well for them. Everyone should use tools they love.
That said, you can write an inaccessible reference cycle that never calls drop() in Rust just as well as you can in most non-GC languages. Leaks are explicitly defined as "safe" in Rust, and IME they're quite common in the wild. Even major projects like Actix had known leaks for several major versions, and you still need to run sanitizers and whatnot to probabilistically find them.
Interestingly, the notion of dropping precisely when something goes out of scope is itself a performance footgun. The pattern of "defer" in Zig encourages thinking in terms of lifetimes and groups of obects, which is much cheaper and easier to reason about.
You can absolutely do that in Rust too, but the language defaults encourage a slightly different programming model, so I see more code that's distasteful to my eyes in that respect in Rust codebases.
- rofrol 2y agokristoff wrote the same about performance > More generally, RAII is a feature that exists in tension with the approach of operating on items in batches, which is an essential technique when writing performance-oriented software. > And it doesn’t end here: operating in batches by using memory arenas, for example, is also a way to reduce memory ownership complexity, since you are turning orchestration of N lifetimes into 1. > In this video Casey Muratori describes how going from thinking about individual allocations to thinking in batches is a natural form of progression for a programmer. > Extremely popular talk on the advantages of looking at problems as data transformation pipelines, where Mike Acton shows how common approaches in C++ (RAII being one of them) are antithetical to the goal of creating performant code. https://kristoff.it/blog/raii-rust-linux/ https://kristoff.it/blog/raii-rust-linux/