Hi Manuel,
A few relies below.
- cquery is based on libclang, while clangd directly works with the AST
and provides a non-LSP C++ interface to be integrated as service in
larger environments - this lets clagnd work in places where libclang is
hard to integrate
Would that C++ interface be usable for out-of-tree projects? I guess one
would simply link to libclangDaemon?
Correct.
I also hope the review mechanism will be more friendly to casual
contributors 
⚙ D40072 [libclang] Support querying whether a declaration is invalid ⚙ D39903 [libclang] Allow pretty printing declarations
⚙ D41575 [index] Return when DC is null in handleReference
Look how nik (Qt Creator clang plugin maintainer) desperately begged for
reviewing 
Hope clangd can be a better replacement of libclang, which kdevelop,
ycmd, rtags, ... and many other projects depend on.
Also hope -index-store-path can change the world 
- clangd wants to integrate with other folks in the community on
indexing interfaces and mechanisms that provide a platform for tools to
work on; while there is also some prototyping, a lot of work goes into
designing the right system
- clangd puts scale and performance first; for very very large code
bases (significantly larger than chromium), this is a precondition, and
(together with the previous item) why we don't have a global index yet
I think cquery puts those two first but it sounds like you have even more
agressive requirements.
Unfortunately, yep 
I believe C++ interface is a more sustainable long-term approach.
But cquery is sufficient for most projects (Chrome, LLVM, Linux kernel,
... which are considered by most people "large projects").
- clangd work currently focuses on making code completion really good,
so quite a bit of work has gone into how to split the preamble and
making completion results better (which also benefits cquery \o/)
The hope is that clangd at some point will catch up with cquery, but as
those things go, in the end they will probably have slightly different
trade-offs, so some folks will use one while others use the other. In
principle that's the nice thing about the LSP; competition is now
possible 
Yeah, clients can adopt one of the other pretty easily (well maybe without
extension support). I think it's good to understand the different
trade-offs and compare the different goals so that potential contributors
can decide where to focus their work.
The feature I missed so much is cross references, and I felt really sad
to see that feature is not prioritized. (I am new to LLVM and I need to
get into it)
A rough figure about cquery: loading index files for llvm+clang+extra+lld (715MiB)
takes 50s on a laptop and 7s on a workstation.
Yep. I'd say if one wants to contribute to continuing to build up a platform
for C++ tooling based on clang, get involved in clangd (I believe this is
specifically a non-goal for cquery); if one wants to get new useful features as
fast as possible, cquery is a better place, and the clangd code reviews will
likely turn out to be a source of frustration, as it often involves getting
consensus across a range of people from different companies 
For everyone interested, come join the talk on clangd at the Euro LLVM
in Bristol; that talk will include a more detailed comparison between
the two approaches.
That sounds very good. I'll be there!
Thank you for your time,
Marc-André
Thank you!