No, you do have to worry about that too in Rust. (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

[2] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

[3] https://doc.rust-lang.org/nomicon/exception-safety.html

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.

> 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.

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.

Thanks. Do you think they'll have time to rewrite Firefox? :) (or Chrome, which encounters the same issues)

Maybe switch to the SerenityOS browser.

I'll be sure to suggest that to Mozilla and Google :)

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.