Fist
Data
full text search server
SHOW HN2019
How HN took it
2 positive, 11 neutral or asking, 0 mixed, 7 critical, out of 20 comments about the project. Thread score -0.26.
Execution: 2 for, 3 againstIdea: 0 for, 2 againstPerformance: 0 for, 2 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Interest in the project and offers of help from commenters
From 2 comments
Hey all, Fist project creator here. Just wanted to thank everyone for the support and the comments. I’ve been working on this project for a few months now mainly as a passion…
max0563 on HNThis is one hell of a comment. Thank you, sir.
max0563 on HN
Objections
Lacks stemming, stopping and relevance ranking expected of full text search
From 2 comments
This seems to be a bit of a stretch in calling it "full-text search" engine: I only casually browsed the code from my phone so I might have missed it, but I don't see any support…
necovek on HNAs others have pointed out there are some features considered essential in this space that would be good additions to the code: Stemming: (removing prefix/suffixes walked,…
michelpp on HN
Written in C, which is hard to make memory safe
From 3 comments
It is irresponsible to the point of professional negligence to write new software in C.
sagichmal on HNC is fast, small, and energy efficient. It is also impossible to write safe, exploit-free code in C by hand. The juice ain’t worth the squeeze.
sagichmal on HNYep, not to bash the author but just to show how easy it is to write unsafe C. First function i started reading i already found a memory leak within a minute: indexer calls…
Too on HN
Hash map lookup is not a real full text search approach; performance claims questioned
From 3 comments
Project Dev here, if you'd be willing to help me with that part I would be greatful. When I talk about "fast" I mean all searches are O(1) due to the magic of hash maps.
max0563 on HNFast FTS use reverse indices with trigrams, not primitive hash maps.
rurban on HNI find it hard to believe that this is "fast" as advertised when it isn't even compiled with optimizations:…
singron on HN
Makefile hardcodes gcc and is not optimized
From 2 comments
Using plain makefiles with "gcc" hardcoded in is atrocious, at least use $(CC). This also raises in me the suspicion that it hasn't been tested with no compiler other than GCC at…
qalmakka on HNI find it hard to believe that this is "fast" as advertised when it isn't even compiled with optimizations:…
singron on HN
Requests
Add HTTP interface
From 2 comments
Looks like the project is still under development but I think that having a http based interface would make this much more accessible to be used easily from multiple languages.…
karterk on HNVery good idea. Can't say I haven't also thought about this. I was also thinking about doing what Tile38 (https://github.com/tidwall/tile38) does and using the REDIS protocol.…
max0563 on HN
Add stemming, stopping and TF-IDF or BM25 ranking
From 2 comments
As others have pointed out there are some features considered essential in this space that would be good additions to the code: Stemming: (removing prefix/suffixes walked,…
michelpp on HNThanks for this! Right now it is not very complicated. An inverted index of the text that is sent over is created and added to the database. The DB is just a big hash map.…
max0563 on HN
Use $(CC) in Makefile and enable optimizations
From 2 comments
Using plain makefiles with "gcc" hardcoded in is atrocious, at least use $(CC). This also raises in me the suspicion that it hasn't been tested with no compiler other than GCC at…
qalmakka on HNI find it hard to believe that this is "fast" as advertised when it isn't even compiled with optimizations:…
singron on HN
Questions
Which algorithm is used for indexing and retrieval
From 1 comment
Very cool project. Which algorithm do you use for indexing/retrieval?
lamchob on HN
Why use Fist over Sphinx or Xapian
From 1 comment
I've been using http://sphinxsearch.com for many years. Why should I consider Fist?
lokl on HN
Alternatives named
Lucene
From 1 comment
Pretty much everyone here knows Lucene as the primary text-search engine these days, but there's a competitor Sphinx Search which is written in C or C++ and is much lighter, to…
aasasd on HN
Xapian
From 2 comments
For simple full text search I like to use SQLite fts3 and Xapian which is a feature rich and mature full text search engine. https://xapian.org/
mitjam on HNI rather keep using xapian. That's a proper indexing and search-engine (C++), much better than sphinx or Elasticsearch. Elasticsearch just has better client integration for…
rurban on HN
Sphinx Search
From 2 comments
I've been using http://sphinxsearch.com for many years. Why should I consider Fist?
lokl on HNPretty much everyone here knows Lucene as the primary text-search engine these days, but there's a competitor Sphinx Search which is written in C or C++ and is much lighter, to…
aasasd on HN
Tantivy
From 1 comment
https://github.com/tantivy-search/tantivy - Lucene in Rust (I have no idea about API or feature parity)
pas on HN
Groonga
From 1 comment
There is also Groonga: https://github.com/groonga/groonga But this looks like it intends to be a lot simpler.
actionowl on HN
Manticore Search
From 1 comment
There's also Manticore, an actively developed fork of the last open-source version of Sphinx: https://manticoresearch.com/about/
yorwba on HN