3 ms·

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-

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.

nemothekid 3y ago
Qdrant is a async Rust project, so there will be lots of Arc. Rust safety guarantees doesn't really let share references across threads haphazardly.
- menaerus 3y ago
  Something being async doesn't imply shared-ptr design. But perhaps this is what Rust makes you to to achieve its safety guarantees?
  - nemothekid 3y ago
    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.
    - menaerus 3y ago
      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.
      - nemothekid 3y ago
        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.
        menaerus 3y ago
        > 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.

nemothekid 3y ago

Qdrant is a async Rust project, so there will be lots of Arc. Rust safety guarantees doesn't really let share references across threads haphazardly.

menaerus 3y ago
Something being async doesn't imply shared-ptr design. But perhaps this is what Rust makes you to to achieve its safety guarantees?
- nemothekid 3y ago
  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.
  - menaerus 3y ago
    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.
    - nemothekid 3y ago
      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.
      - menaerus 3y ago
        > 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.