Live data from Hacker News

Show HN: I wrote a full text search engine in Go

github.com

31–40 of 56 posts

Re: Show HN: I wrote a full text search engine in Go

#31

Shameless plug, you may wish to do Lucene-style tokenizing using the Unicode standard: https://github.com/clipperhouse/uax29/tree/master/words

Got to admit, initial impressions, this is pretty neat, would spend sometime with this. Thanks for the link :)

Re: Show HN: I wrote a full text search engine in Go

#32

I really liked the README, that was a good use of AI. If you're interested in the idea of writing a database, I recommend you checkout https://github.com/thomasjungblut/go-sstables which includes sstables, a skiplist, a recordio format and other database building blocks like a write-ahead log. Also https://github.com/BurntSushi/fst which has a great Blog post explaining it's compression (and been ported to Go) which…

>>I wrote a full text search engine in Go

>I really liked the README, that was a good use of AI.

Human intelligences, please start saying:

(A)I wrote a $something in $language.

Give credit where is due. AIs have feelings too.

Re: Show HN: I wrote a full text search engine in Go

#34
post #25

Earlier quoted context omitted.

Another possible tell (not saying this is vibe coded) is when every function is documented, almost too much comments

Ohh, I thought that inline comments would make it grokkable and be a low-friction way in. Seems this didn’t land the way I intended :' Should a multi-part blog would've been better?

I like it, I comment exactly like you do. Comments are free, storage is plentiful, why not add comments everywhere?!

Re: Show HN: I wrote a full text search engine in Go

#35

I really liked the README, that was a good use of AI. If you're interested in the idea of writing a database, I recommend you checkout https://github.com/thomasjungblut/go-sstables which includes sstables, a skiplist, a recordio format and other database building blocks like a write-ahead log. Also https://github.com/BurntSushi/fst which has a great Blog post explaining it's compression (and been ported to Go) which…

>> I wrote a full text search engine in Go >I really liked the README, that was a good use of AI . Human intelligences, please start saying: ( A )I wrote a $something in $language. Give credit where is due. AIs have feelings too.

> AIs have feelings too

Ohh boi, that’s exactly how the movie "Her" started! XD

Re: Show HN: I wrote a full text search engine in Go

#36

Did you vibe code this? A few things here and there are a bit of a giveaway imho.

On my way to make a Dexter meme on this When you think OP vibe-coded the project but can’t prove it yet https://x.com/FG_Artist/status/1974267168855392371

OH YES! I Love it/this meme lol!!

Dexter's memes have been popping up recently and I am loving them

I don't know who bay harbor butcher is though :sob: but I don't want spoilers, I will watch it completely some day

My friend says that he watched complete dexter just via clips lol.

Re: Show HN: I wrote a full text search engine in Go

#38
post #19

Earlier quoted context omitted.

Probably the commit history.

Yayiee, the “cant prove it” Doakes Dexter meme, making it to HN

You are neither confirming nor denying, why won't you just tell if you vibe-coded it or not?

Re: Show HN: I wrote a full text search engine in Go

#39
This is pretty interesting.

Could you explain more why you avoided parsing strings to build queries? Strings as queries are pretty standard for search engines. Yes, strings require you to write an interpreter/parser, but the power in many search engines comes from being able to create a query language to handle really complicated and specific queries.

Re: Show HN: I wrote a full text search engine in Go

#40

This is pretty interesting. Could you explain more why you avoided parsing strings to build queries? Strings as queries are pretty standard for search engines. Yes, strings require you to write an interpreter/parser, but the power in many search engines comes from being able to create a query language to handle really complicated and specific queries.

You're right, string-based queries are very expressive. I intentionally avoided that here so readers could focus on how FTS indexes work internally. Adding a full query system would have shifted the focus away from the internals.

If you notice there are vv obvious optimizations we could make. I’m planning to collect them and put a these as code challenges for readers, and building string-based queries would make a great one :)

Post reply on HN