> In addition to that, I feel like pointing out that destructors generally compile down to nothing. Really? If that's true then RAII didn't do anything in the

> In addition to that, I feel like pointing out that destructors generally compile down to nothing. Really? If that's true then RAII didn't do anything in the first place and you could do without it. And the "everybody uses goto" is a "defer/errdefer" pattern rather than an RAII pattern. So, in at least 2/3 of the cases, you don't need the full power of RAII and all the problems it brings. > I think the anti-Rust people would be better off arguing that they just don't like RAII because it's "magic" (ie. too implicit about cleanup). It's harder to argue against because it's subjective, whereas these arguments against RAII are specious at best. The big failure point is when your RAII object escapes local scope (ie. you pass it back or put it into a container data structure). RAII means that the entity who gets charged with deallocation is different form the entity who created the allocation. This is the exact same problem as the old C problem of "allocate an object in one function but expect a different function to deallocate it". C old timers excoriate anyone who does this for good reason. Sure, RAII in Rust means you don't core dump; your performance characteristics just become non-deterministic. This kind of cleanup action at a distance is essentially "garbage collection" by any other name--only less well controlled. Quite often the whole point of using a systems programming language is to avoid garbage collection non-determinism--that chunk of people are going to be very upset to see it come back via RAII.