alexflint

We really did think a lot about this. It turns out that there is no clean separation between "index code" and "query for results". E.g. In Python if you see x.foo() you may need to know a _lot_ about the universe of Python libraries to do the type inference required to figure out what foo is in that particular expression.

Alex from kite here. Re privacy: we totally agree that it's a legit concern. when we started working on this we realized if we wanted to index tens of thousands of libraries, we wouldn't be able to ship the entire index along with the client. Hence the cloud-based architecture. We've thought a lot about privacy and written up our thoughts here: www.kite.com/privacy. The short answer is: we don't index anything on your computer that you don't explicitly ask us to, and our plan is to earn trust the hard (i.e. only) way: transparency, published policies, and a track record of good decision making.

Thanks for the feedback. One of the motivations behind go-restructure was to help with regex composition. This happens to be particularly pressing at my day job where we have a few small regexes that get copied into lots of larger regexes, which means that when we find a bug in the small regex we have to go and update lots of other strings.

One alternative is to build up regexes dynamically concatenating smaller regexes, but that leads to whole other kind of hell.

Thanks! I'm planning to do some benchmarking so will hopefully have something up in the next few days.

Thanks! This is now merged in.