3 ms·

> The drop trait has its warts too. Zig's version sets up a point in time where the given cleanup code _will_ run (ignoring power outages and the like), and Rus

> The drop trait has its warts too. Zig's version sets up a point in time where the given cleanup code _will_ run (ignoring power outages and the like), and Rust's sets up a point in time where the given cleanup code is _allowed_ to run. You're making it sound like Drop is regularly not called, which could lead someone to think that you're talking about them not running on panics, which they do: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e1f04f91722cc4220995f4bda922ed70 https://play.rust-lang.org/?version=stable&mode=debug&editio... The reason they are allowed to run is because panics can be configured to be abort, so people are discouraged from using Drop to maintain safety constraints. But any language will have issue executing code before exiting if you go out of your way to set things up so normal unwinding doesn't occur. > It solves UAF, but it makes performance harder to reason about and makes leaks easier to write (a common theme in my complaints about Rust -- it's mostly a nice language, but many of the design choices slightly encourage leaky code, so most projects of any size and complexity have leaks). I don't see how Drop causes leaks. > Having drops be that easy to write also encourages programmers to think in terms of small units of data rather than collections and common lifetimes, typically resulting in increased execution times. Beyond my skepticism about the mechanism being a significant source of performance degradation, writing collections that take responsibility over dropping their contents in one go isn't particularly difficult or restricted by the language.

hansvm 2y ago
> You're making it sound like Drop is regularly not called Sorry if it came across that way. My claim is weaker, that it's sometimes not called even in cases where it could be with a smart enough programmer/language. > But any language will have issue executing code before exiting if you go out of your way to... Is there an easy way to make Drop work nicely with signal handler induced shutdowns other than having a "correctly" configured panic handler and panicking in the signal handler (even that causing other UB depending on what code Drop runs)? The edge cases for the feature look thorny from my perspective, but (some) other languages handle that by forcing you to be explicit about which code runs when. > I don't see how Drop causes leaks "Relying" on Drop is the most common source of Drop-related leaks. All it takes is one extra reference to cause leaky code (see Actix as a case study in such problems). > Beyond my skepticism about the mechanism being a significant source of performance degradation That's... pretty easy to test? Pick any problem that potentially has a lot of allocations, like an async sudoku solver, and check how it performs with a collection (arena, pool, ...) vs using Drop on each item. I promise the difference is substantial. > writing collections that take responsibility over dropping their contents in one go isn't particularly difficult or restricted by the language No, not at all. I totally agree. The concept of "intentional friction" is useful here. An expert can make excellent Rust code. My last job had one person like that (not that it matters, but that was out of many people who wrote Rust there), and you have shining examples like BurntSushi. My complaint is that the language's happy path doesn't guard against those performance mishaps, and since most Rust code I see in the wild has fallen prey to those pitfalls I think it's a reasonable complaint.

hansvm 2y ago

> You're making it sound like Drop is regularly not called Sorry if it came across that way. My claim is weaker, that it's sometimes not called even in cases where it could be with a smart enough programmer/language. > But any language will have issue executing code before exiting if you go out of your way to... Is there an easy way to make Drop work nicely with signal handler induced shutdowns other than having a "correctly" configured panic handler and panicking in the signal handler (even that causing other UB depending on what code Drop runs)? The edge cases for the feature look thorny from my perspective, but (some) other languages handle that by forcing you to be explicit about which code runs when. > I don't see how Drop causes leaks "Relying" on Drop is the most common source of Drop-related leaks. All it takes is one extra reference to cause leaky code (see Actix as a case study in such problems). > Beyond my skepticism about the mechanism being a significant source of performance degradation That's... pretty easy to test? Pick any problem that potentially has a lot of allocations, like an async sudoku solver, and check how it performs with a collection (arena, pool, ...) vs using Drop on each item. I promise the difference is substantial. > writing collections that take responsibility over dropping their contents in one go isn't particularly difficult or restricted by the language No, not at all. I totally agree. The concept of "intentional friction" is useful here. An expert can make excellent Rust code. My last job had one person like that (not that it matters, but that was out of many people who wrote Rust there), and you have shining examples like BurntSushi. My complaint is that the language's happy path doesn't guard against those performance mishaps, and since most Rust code I see in the wild has fallen prey to those pitfalls I think it's a reasonable complaint.