IMHO it looks arcane to understand or to debug, and with most likely a lot of negative performance implications, due to its shared-ptr-in-disguise all-over-the-place design.
$ git grep "Arc<" | wc -l
451
It could be probably related to the fact that the main author of the codebase is coming from the Java/Scala world. Or perhaps it's the Rust safety guarantees.
Yes; in many cases, if there are two tasks that hold some piece of data, the compiler cannot, at compile time, when to free that data, as it doesn't know which of the two tasks will finish first.
That means the lifetime of that object must be tracked at runtime, with a garbage collector. This is where you get Arc (or shared-ptr).
I'm not sure how you would safely solve this in C++, but FWIW, scylladb is a high performance database that also makes use of shared_ptr.
Multi-threaded and/or async code can perfectly exist without shared-ptrs. And no, you don't need a shared-ptr to manage the lifetime of an object shared by two threads.
That might be true of C++, but I don't think its true in Rust. Furthermore, I don't think the performance concern is as dire as you believe - both Scylla and Redpanda, two high performance C++ databases both use shared_ptr with their async framework Seastar.
> That might be true of C++, but I don't think its true in Rust
And which was exactly my point.
> both Scylla and Redpanda, two high performance C++ databases both use shared_ptr
Such argument doesn't make sense since you will find usage of shared-ptrs in probably more or less every high performance C++ codebase out there. The secrete sauce is to know _where_ and _when_ to use it. I'm not against it but I'm definitely not in favor of language forcing me to user it when I don't need it.
