5 ms·

I wanted to write a similar comment, but then noticed that the paper claims 100% safety by using an analysis tool, not just by convention. Agreed about the pot

I wanted to write a similar comment, but then noticed that the paper claims 100% safety by using an analysis tool, not just by convention. Agreed about the potential of Rust, it sidesteps most of these problems. Though it might introduce other problems of its own, only time will tell. I expect that Rust's future sore spots will include destructor leaks, the reliance on macros, and the tremendous complexity of traits. (Though of course I don't claim to have better solutions to those.)

kibwen 11y ago
> destructor leaks Rust doesn't leak destructors any more than C++ (including the version of C++ presented in the OP). The only way to leak a destructor accidentally is to create a cycle (which is quite difficult to do, essentially requiring you to stuff a RefCell inside an Rc) or to have some data owned by a thread that's eternally stalled. > reliance on macros Individual macros are generally regarded as convenient workarounds rather than ideal long-term solutions, and anywhere that you see pervasive macro use tends to be ripe for an RFC for a dedicated feature to subsume it. > the tremendous complexity of traits No denying that traits are Rust's "deepest" feature, but that's because of a general philosophy to leverage traits to provide newly desired bits of functionality rather than introducing all-new language concepts. Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere.
- kbenson 11y ago
  > Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere. Yes, the Waterbed Theory of Complexity[1]. It can be useful to funnel complexity into specific areas where it's at least expected, and there may exist better mechanisms for dealing with it. 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
- cousin_it 11y ago
  > destructor leaks Right, I'm not saying C++ is perfect either. I feel like Rust made a wrong turn here: https://www.reddit.com/r/rust/comments/3404ml/prepooping_your_pants_with_rust/ https://www.reddit.com/r/rust/comments/3404ml/prepooping_you... > reliance on macros I'm referring specifically to try!.
  - kibwen 11y ago
    > I feel like Rust made a wrong turn here I think the broader context of "the leakpocalypse" involved a host of difficult decisions, all of them suboptimal in their own ways. Of all the options on the table, it's my opinion that Rust took the most pragmatic one, especially given that the proposals that sought to ensure "never-leak" behavior all felt like they had undiscovered holes of their own, leading to a lot of ceremony for no actual benefit. > I'm referring specifically to try! I'm also referring to `try!`. :) It's a personal goal of mine this year to advocate a language-level replacement (and enhancement) for improved error-handling ergonomics.
  - Manishearth 11y ago
    Note that whilst the leakpocalypse made it safe to leak, it's not a common case. Leaking safely involves an explicit call to mem::forget or extremely convoluted code involving Rc cycles. Its pretty much going to happen in languages which provide refcounted pointers. None of the proposed solutions mitigated this either. You will always be able to leak cycles. The difference was that some proposals made it possible to mark types as non-leakable, in which case they can't be placed in things which may potentially leak. The fact that things will leak was never under question there. The decision to be made was on how safety should interact with it -- should there be a way for a type to rely on its destructor being run for the purposes of safety? The decision was that there shouldn't, and we ended up fixing two APIs which relied on destructors being run for safety, instead of adding a major language change.
    - cousin_it 11y ago
      For what it's worth, I feel that marking types is also a mistake, and the whole machinery of OIBITs exists due to some unfortunate decisions made early on. Maybe the cleanest solution to the leakpocalypse would be to mark RefCell.borrow_mut as unsafe, because it's problematic in two separate ways (it can both panic and create cycles). That way the safe fragment of Rust would guarantee that memory leaks can't happen and destructors always run. That would fit with the spirit of Rust, which strongly prefers 100% guarantees to 99% guarantees. Though I guess that idea was judged too inconvenient for users, and I don't claim to know what users want.
MichaelMoser123 11y ago
There is this cppcon presentation by Stroustrup where he is talking about the GSL annotations https://m.youtube.com/watch?v=1OEu9C51K2A https://m.youtube.com/watch?v=1OEu9C51K2A but too bad that it all depends on this unreleased big black box proprietary code analysis tool.
- MichaelMoser123 11y ago
  The problem is that you probably can't trust the validator results blindly. You will end up with at least some false reports.

kibwen 11y ago

> destructor leaks Rust doesn't leak destructors any more than C++ (including the version of C++ presented in the OP). The only way to leak a destructor accidentally is to create a cycle (which is quite difficult to do, essentially requiring you to stuff a RefCell inside an Rc) or to have some data owned by a thread that's eternally stalled. > reliance on macros Individual macros are generally regarded as convenient workarounds rather than ideal long-term solutions, and anywhere that you see pervasive macro use tends to be ripe for an RFC for a dedicated feature to subsume it. > the tremendous complexity of traits No denying that traits are Rust's "deepest" feature, but that's because of a general philosophy to leverage traits to provide newly desired bits of functionality rather than introducing all-new language concepts. Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere.

kbenson 11y ago
> Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere. Yes, the Waterbed Theory of Complexity[1]. It can be useful to funnel complexity into specific areas where it's at least expected, and there may exist better mechanisms for dealing with it. 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
cousin_it 11y ago
> destructor leaks Right, I'm not saying C++ is perfect either. I feel like Rust made a wrong turn here: https://www.reddit.com/r/rust/comments/3404ml/prepooping_your_pants_with_rust/ https://www.reddit.com/r/rust/comments/3404ml/prepooping_you... > reliance on macros I'm referring specifically to try!.
- kibwen 11y ago
  > I feel like Rust made a wrong turn here I think the broader context of "the leakpocalypse" involved a host of difficult decisions, all of them suboptimal in their own ways. Of all the options on the table, it's my opinion that Rust took the most pragmatic one, especially given that the proposals that sought to ensure "never-leak" behavior all felt like they had undiscovered holes of their own, leading to a lot of ceremony for no actual benefit. > I'm referring specifically to try! I'm also referring to `try!`. :) It's a personal goal of mine this year to advocate a language-level replacement (and enhancement) for improved error-handling ergonomics.
- Manishearth 11y ago
  Note that whilst the leakpocalypse made it safe to leak, it's not a common case. Leaking safely involves an explicit call to mem::forget or extremely convoluted code involving Rc cycles. Its pretty much going to happen in languages which provide refcounted pointers. None of the proposed solutions mitigated this either. You will always be able to leak cycles. The difference was that some proposals made it possible to mark types as non-leakable, in which case they can't be placed in things which may potentially leak. The fact that things will leak was never under question there. The decision to be made was on how safety should interact with it -- should there be a way for a type to rely on its destructor being run for the purposes of safety? The decision was that there shouldn't, and we ended up fixing two APIs which relied on destructors being run for safety, instead of adding a major language change.
  - cousin_it 11y ago
    For what it's worth, I feel that marking types is also a mistake, and the whole machinery of OIBITs exists due to some unfortunate decisions made early on. Maybe the cleanest solution to the leakpocalypse would be to mark RefCell.borrow_mut as unsafe, because it's problematic in two separate ways (it can both panic and create cycles). That way the safe fragment of Rust would guarantee that memory leaks can't happen and destructors always run. That would fit with the spirit of Rust, which strongly prefers 100% guarantees to 99% guarantees. Though I guess that idea was judged too inconvenient for users, and I don't claim to know what users want.

MichaelMoser123 11y ago

There is this cppcon presentation by Stroustrup where he is talking about the GSL annotations https://m.youtube.com/watch?v=1OEu9C51K2A https://m.youtube.com/watch?v=1OEu9C51K2A but too bad that it all depends on this unreleased big black box proprietary code analysis tool.

MichaelMoser123 11y ago
The problem is that you probably can't trust the validator results blindly. You will end up with at least some false reports.