Why is AGPL bad? It would prevent Amazon from taking it from the founders and making money off it without giving anything back, like they did to dozens other products.

It also makes it less interesting for other potential customers to use it. Reducing the potential market is probably not what a VC funding a startup wants.

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.

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.

Something being async doesn't imply shared-ptr design. But perhaps this is what Rust makes you to to achieve its 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.