It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.
It's important to understand the difference between data races and race conditions. The former are a subset of the latter. Race conditions in general can happen even in single-threaded code. (Although admittedly Rust ownership semantics prevent many of the latter as well; for instance, modifying a collection while iterating over it is impossible, cf. Java `ConcurrentModificationException` which itself is thrown only on a best-effort basis.)
Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations).
I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).
Exceptions are mostly annoying because they’re infectious, and somewhat undocumented (they’ve not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won’t say a word about it (unless its java, in which case you’ll probably get too much :-). Return codes are similar, but less cascade-y. Try-catch being verbose and fucking up control flow is just an added bonus.
