Show HN: An experimental code search engine

For example, if I enter “UDP broadcast” into your search, I find all the usual java and cpp results that I can find anywhere. Ho hum. If I wanted those, I could go use Google or probably just trip over them in my living room.

But I want results in Swift because it is relatively new and obscure. There are only 4 Swift projects on Github that match the term “UDP broadcast” out of 319 total results. I have to do an advanced search on the native Github engine to find them.

I think you might want to start by making your search useful for finding the weird obscure things that people really have to hunt for. Then expand it to everything else while finding a way of not drowning the oddball stuff with the common clay (of the New West).

This is where Google, for example, has gone wrong lately. I almost can’t use it for anything meaningful because any meaningful search (example ‘MacOS gps”) brings back “5 Amazing GPS apps for Mac that you can’t live without!!” and many other links with no actual content.

If you want to make a useful search, you have to return the stuff that is hard to find instead of the easy and useless stuff.

I'm already devising how you could incorporate a bag of words algorithm plus an embedding to segment/find similar items.

Imagine a series of search boxes, with the results of the first fed into the second, and so on. Like:

> codegrep --class "Logger" | codegrep --field "error"

Like for a package say `sync` I want to see the most common methods first and their documentation.

I find the current godocs lacks in giving welcoming vibes and treat every aspect of a package equally where some method types are more important/useful than others.

How do you think about Elm? I want to do more work with it too, play with it on some toy projects and love it so far.