5 ms·

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panace

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panacea, but it does eliminate certain concerns that C++ just can not remove from thought while developing with it. The great thing about Rust is that it reduces the knowledge and skill a developer needs in order to write a stable and (usually) performant program. This is a good thing.

nyanpasu64 4y ago
Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a representative example is https://github.com/Storyyeller/stable_deref_trait/issues/15 https://github.com/Storyyeller/stable_deref_trait/issues/15) that I'd rather write C++ than unsafe Rust.
- bluejekyll 4y ago
  You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs. Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this. In Rust, we try to isolate unsafe usage and test it excessively. In C++ you have no such option.
  - nyanpasu64 4y ago
    So far I have found no Rust insertion-ordered collections which supports removing items without scrambling items (necessary for editing a key-value INI file) with O(log n) reads/writes, though you can use a vector with O(n) accesses which takes O(n^2) to lookup every key, which is probably good enough in most cases. And non-tree-shaped object graphs are not a library concern, but permeate entire applications; if you want to rewrite an app using shared mutability in Rust, you must either write code awkwardly with Cell/RefCell (and RefCell has runtime overhead), restructure the whole program in one Big Rewrite, or fallback to unsafe accesses (at this point, outside of multithreading C++ is a better Unsafe Rust than Unsafe Rust). Please respond with a factual rebuttal before downvoting.
    - paavohtl 4y ago
      It seems that indexmap would fit your bill: Repo: https://github.com/bluss/indexmap https://github.com/bluss/indexmap IndexMap type itself: https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap.html https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap... It has amortized O(1) reads and writes, and it supports removal without maintaining order in O(1), or while maintaining order in O(n).
      - nyanpasu64 4y ago
        I was not initially aware of O(n) order-preserving shift_remove[...](). Although likely not a problem in practice, removing a large number of items one by one (eg. when a user is deleting a selection containing many file associations) can result in quadratic behavior. I found that you can avoid that by calling retain() (at the cost of being a higher-order function) to keep/remove every item in the list in a single pass (linear time is fast enough for INI files). So in retrospect IndexMap would be a workable choice, if used carefully.
blablableu 4y ago
There are entire classes of bugs that cannot happen in (safe) Java/Erlang/Scheme/etc. that can still happen in a "bug free" Rust code base.
- bluejekyll 4y ago
  Like? I know that you’re trolling, but looking at Java specifically, the error handling in Rust and RAII pattern in Rust ensures that things like file handles are cleaned up. Modern Java has made this nicer, but it still offers a lot of potential bugs around resource leaks. Sticking with Java, Rust also offers a better story around thread safety, such that sharing mutable state across threads requires types that allow that to work. Finally, Java’s exception handling and null usage generally allows a lot of low hanging fruit bugs to slip through where in Rust these types of errors are far less likely to happen. I never said Rust is “bug free”, I’ve been working with software far to long to make such a provably wrong statement.
mbrodersen 4y ago
I completely agree with you. Rust seems to be a good step forward.

nyanpasu64 4y ago

Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a representative example is https://github.com/Storyyeller/stable_deref_trait/issues/15 https://github.com/Storyyeller/stable_deref_trait/issues/15) that I'd rather write C++ than unsafe Rust.

bluejekyll 4y ago
You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs. Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this. In Rust, we try to isolate unsafe usage and test it excessively. In C++ you have no such option.
- nyanpasu64 4y ago
  So far I have found no Rust insertion-ordered collections which supports removing items without scrambling items (necessary for editing a key-value INI file) with O(log n) reads/writes, though you can use a vector with O(n) accesses which takes O(n^2) to lookup every key, which is probably good enough in most cases. And non-tree-shaped object graphs are not a library concern, but permeate entire applications; if you want to rewrite an app using shared mutability in Rust, you must either write code awkwardly with Cell/RefCell (and RefCell has runtime overhead), restructure the whole program in one Big Rewrite, or fallback to unsafe accesses (at this point, outside of multithreading C++ is a better Unsafe Rust than Unsafe Rust). Please respond with a factual rebuttal before downvoting.
  - paavohtl 4y ago
    It seems that indexmap would fit your bill: Repo: https://github.com/bluss/indexmap https://github.com/bluss/indexmap IndexMap type itself: https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap.html https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap... It has amortized O(1) reads and writes, and it supports removal without maintaining order in O(1), or while maintaining order in O(n).
    - nyanpasu64 4y ago
      I was not initially aware of O(n) order-preserving shift_remove[...](). Although likely not a problem in practice, removing a large number of items one by one (eg. when a user is deleting a selection containing many file associations) can result in quadratic behavior. I found that you can avoid that by calling retain() (at the cost of being a higher-order function) to keep/remove every item in the list in a single pass (linear time is fast enough for INI files). So in retrospect IndexMap would be a workable choice, if used carefully.

blablableu 4y ago

There are entire classes of bugs that cannot happen in (safe) Java/Erlang/Scheme/etc. that can still happen in a "bug free" Rust code base.

bluejekyll 4y ago
Like? I know that you’re trolling, but looking at Java specifically, the error handling in Rust and RAII pattern in Rust ensures that things like file handles are cleaned up. Modern Java has made this nicer, but it still offers a lot of potential bugs around resource leaks. Sticking with Java, Rust also offers a better story around thread safety, such that sharing mutable state across threads requires types that allow that to work. Finally, Java’s exception handling and null usage generally allows a lot of low hanging fruit bugs to slip through where in Rust these types of errors are far less likely to happen. I never said Rust is “bug free”, I’ve been working with software far to long to make such a provably wrong statement.

mbrodersen 4y ago

I completely agree with you. Rust seems to be a good step forward.