[comrad]

Just because it is in C++ it is supposed to be faster? I highly doubt that.

[Minor49er]

I don't see anywhere where they claim that it's faster simply because it's written in C++. They do mention that they make use of C++ to add low level optimizations that make queries faster and the memory imprint smaller, but any claims about performance in the readme are linked to benchmarks to back up their claims

https://github.com/manticoresoftware/manticoresearch/

https://db-benchmarks.com/test-taxi/#manticore-search-vs-ela...

[snikolaev]

It is unlikely that it is because of C++, however, we have conducted extensive benchmarking (which, by the way, is fully open-source and can be easily reproduced if desired). You can find more information about this at https://manticoresearch.com/blog/manticore-alternative-to-el....

[Shorel]

No, just because it's in C++ does not mean it is automatically faster.

However, with good enough algorithms and judicious coding and memory management, the possibility exists.

[danudey]

Also, architectural changes. They describe how ES can't parallelize a query unless it's spread across multiple index shards, which has its own tradeoffs. Their query engine can parallelize a query on a single index shard, which means it scales much more linearly on more cores without having to make those tradeoffs.

[pjmlp]

Same can be said by Java, even without direct support for value types.

Plus it doesn't need to be Java xor C++, JNI exists for a reason (now Panama).

[alphanullmeric]

Someone tell the rust people

[janmo]

It is, and also it is the way c/c++ makes you write code.

Languages such as Java or PHP make you lazy and you end up using the string variable type a lot. It is extremely inefficient.

[Conscat]

C/++ actually make you write relatively slow code too, by default. Not to the extent of Java, but still there is HUGE room for improvement in libC and by extension the STL. I'm working on a slash-and-burn approach to the problem here: https://github.com/cons-cat/libcat