HN user
A lot of vlang-related statistics are very suspicious, probably some of the metrics are boosted by a click farm or something similar. For example, 99% of the global google searches about "vlang" are from Beijing. https://trends.google.com/trends/explore?date=today%205-y&q=...
I already explained to you why I didn't open more than one PR to the project, I'm not trolling anyone: without knowing Clojure the only contribution that I could do without spending literally days of work is just the use of System.nanoTime() instead of System.currentTimeMillis(). The reason why I don't write the other benchmarks in Java is because reimplementing anything from zero costs precious time, that I don't have. If you don't have time too, instead of closing the issues and calling me a troll, you can just say that; you are taking some valid critiques as a personal attack.
It's true that I'm just an university student and you are a scientist, a researcher, a professor, and an enterpreneur, but it doesn't mean that I can't be knowledged as you in very narrow fields. I'm currently running a personal project that uses Lucene since four years ago, with about 8 billion messages and 340 million chats stored in a distributed lucene index, so I'm not the regular troll or a person that just talks without knowing anything. I surely can't critique your T-WAND algorithm, that it seems to be good in your use case, but with all the humilty in the world I can say to have the minimum knowledge required to spot some weird usages of Lucene APIs.
I never had the interest to "talk down Datalevin", I criticized the results because the title was quite misleading in the tones and the benchmarks were not rigorous enough to express conclusive statements.
I opened a PR to use the more precise timers. This would not improve the performance of any of the tests, but it will improve their time accuracy.
I highlighted some other problems related to the Lucene benchmark, but since I can't program in Clojure I can't fix them with a PR: I opened 3 issues to describe what can be done to address them.
You completely misunderstood what this project does. This kind of libraries do not force you to return results in a specific way. Generally they allow the programmer to customize how the results are scored and chosen.
That's not true. The real problem is that he is implying that his software is faster than Lucene showing data from a benchmark that has substantial flaws. The reason why the majority of criticism comes from Lucene users is because they generally have a higher knownledge about this field than the people that read this article without having the basic knowledge to form any kind of criticism
I also suggest you to look at his "benchmarks" code
He is beating lucene only if you look at his broken benchmark
The funny thing is that the benchmarks that he wrote are more problematic than the T-WAND code itself.
He didn't use any benchmarking library, and he used System.currentTimeMillis instead of the high precision timer available with System.nanoTime.
He also instantiated the IndexSearcher without specifying any executor and he instantiated the legacy query parser on every lucene search
The benchmarks in question have several implementation issues, I reported them on GitHub.
https://github.com/juji-io/datalevin/issues/created_by/caval...
Now it's online
Looking at gitly repository it almost has no features, only a fraction of the basic git features are present, and they are barely working. Why is it being advertised here on HN as a fast alternative of github/gitlab?
P.S.: Probably the website crashed, it's giving me 502 bad gateway from cloudflare
They also care about criticism https://imgur.com/a/8wYsj4C