4 ms·

> enables the enforcement of strong invariants My experience has been the opposite. Ensuring exception safety in a type that has nontrivial move/copy operators

> enables the enforcement of strong invariants My experience has been the opposite. Ensuring exception safety in a type that has nontrivial move/copy operators (that is, a type that for whatever reason can’t follow the “rule of zero”) is often a research-level problem. Not having to worry about that in Rust is such a breath of fresh air.

mgaunard 4y ago
Enforcing basic exception safety is trivial, you just have to follow very simple rules. Enforcing strong exception safety might require some thought, but it's definitely not "a research-level problem". In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc. Regardless, how the invariants of your objects are maintained in case of operation failure is something you should be thinking of regardless of the language.
- Yoric 4y ago
  > Enforcing basic exception safety is trivial, you just have to follow very simple rules. That's not my experience as a C++ developer in a complex, cross-platform, application, which needs to: 1. interact with C; 2. operate with an event loop; 3. operate/interact with a GC; 4. interact with non-trivial system libraries (e.g. Direct3D, Vulkan, ...) > In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc. The borrow checker is indeed complicated. I'm not sure how you define "satisfying", though. As for (A)rc, it can definitely be interpreted as a "cop-out" or as delaying optimization until you actually have good reasons to believe that you need it.
  - mgaunard 4y ago
    I'm sorry to hear that you haven't been successful in using C++ features to their full potential in environments tightled coupled with C libraries. Integration with C or C-like code usually requires some effort if you want to be able to use exceptions that could propagate through C. I do not offer consulting but can refer you to people who do.
    - Yoric 4y ago
      Thanks. Do you think they'll have time to rewrite Firefox? :) (or Chrome, which encounters the same issues)
      - moloch-hai 4y ago
        Maybe switch to the SerenityOS browser.
        Yoric 4y ago
        I'll be sure to suggest that to Mozilla and Google :)
      - mgaunard 4y ago
        Well, from what you were saying, it's mostly a problem of making your asynchronous framework work well with exceptions. It is true that you need to do special things for asynchronous programming to work well in C++, be it for exceptions or even the scope-bound lifetime management of C++ in general, which all have a huge impact on the design of your system. In particular most multi-threaded C++ code is incorrect, not because it is impossible to do it correctly, but because the standard tooling is too low-level, each third-party framework targets a different niche, and people who roll their own tend to hack it together. I understand Seastar is supposed to do it somewhat correctly, so you could suggest to Mozilla that they switch to that.
cyber_kinetist 4y ago
No, you do have to worry about that too in Unsafe Rust if you want to achieve memory safety. (If you're writing only Safe Rust then probably not, but then that also applies to C++ if you're adhering to the rule of zero and extensively use the STL containers for all your memory allocation needs.) Exceptions do exist in Rust, and you do need to catch it explicitly at the FFI boundary. [1][2] And the programmer needs to take care their abstractions are safe with stack unwinding when writing any kind of unsafe code in Rust. (For an example: [3]) [1] https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html [2] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [3] https://doc.rust-lang.org/nomicon/exception-safety.html https://doc.rust-lang.org/nomicon/exception-safety.html

mgaunard 4y ago

Enforcing basic exception safety is trivial, you just have to follow very simple rules. Enforcing strong exception safety might require some thought, but it's definitely not "a research-level problem". In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc. Regardless, how the invariants of your objects are maintained in case of operation failure is something you should be thinking of regardless of the language.

Yoric 4y ago
> Enforcing basic exception safety is trivial, you just have to follow very simple rules. That's not my experience as a C++ developer in a complex, cross-platform, application, which needs to: 1. interact with C; 2. operate with an event loop; 3. operate/interact with a GC; 4. interact with non-trivial system libraries (e.g. Direct3D, Vulkan, ...) > In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc. The borrow checker is indeed complicated. I'm not sure how you define "satisfying", though. As for (A)rc, it can definitely be interpreted as a "cop-out" or as delaying optimization until you actually have good reasons to believe that you need it.
- mgaunard 4y ago
  I'm sorry to hear that you haven't been successful in using C++ features to their full potential in environments tightled coupled with C libraries. Integration with C or C-like code usually requires some effort if you want to be able to use exceptions that could propagate through C. I do not offer consulting but can refer you to people who do.
  - Yoric 4y ago
    Thanks. Do you think they'll have time to rewrite Firefox? :) (or Chrome, which encounters the same issues)
    - moloch-hai 4y ago
      Maybe switch to the SerenityOS browser.
      - Yoric 4y ago
        I'll be sure to suggest that to Mozilla and Google :)
    - mgaunard 4y ago
      Well, from what you were saying, it's mostly a problem of making your asynchronous framework work well with exceptions. It is true that you need to do special things for asynchronous programming to work well in C++, be it for exceptions or even the scope-bound lifetime management of C++ in general, which all have a huge impact on the design of your system. In particular most multi-threaded C++ code is incorrect, not because it is impossible to do it correctly, but because the standard tooling is too low-level, each third-party framework targets a different niche, and people who roll their own tend to hack it together. I understand Seastar is supposed to do it somewhat correctly, so you could suggest to Mozilla that they switch to that.

cyber_kinetist 4y ago

No, you do have to worry about that too in Unsafe Rust if you want to achieve memory safety. (If you're writing only Safe Rust then probably not, but then that also applies to C++ if you're adhering to the rule of zero and extensively use the STL containers for all your memory allocation needs.) Exceptions do exist in Rust, and you do need to catch it explicitly at the FFI boundary. [1][2] And the programmer needs to take care their abstractions are safe with stack unwinding when writing any kind of unsafe code in Rust. (For an example: [3]) [1] https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html [2] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [3] https://doc.rust-lang.org/nomicon/exception-safety.html https://doc.rust-lang.org/nomicon/exception-safety.html