alexflint

It wouldn't be a viable business unless we thought we could add real value _and_ thought that we could capture some of that value. Yes, being on the cloud allows us to set up an attractive subscription model. But Kite won't succeed as a business unless it turns out to actually be a value-add over local solutions. That's what we're betting on.

No we don't do anything with the terminal any more (and in particular we do not record terminal commands in any way)

We actually almost delayed launch to get linux support in because it's very close to ready. Several of us internally develop on linux and have been using Kite on linux for a while.

Regarding features, there's actually more than just autocomplete and docs: https://kite.com/tour/atom

That's right: https://kite.com/tour/atom

I actually agree that under many languages/editors it's so difficult and finicky to set up autocomplete that it's not worth doing. We actually think that's a strength of the Kite model where we offload this stuff to the cloud and provide this stuff as a service.

Oops! That message is a remnant of the distant past and does not correspond in any way to what is actually happening under the hood.

Yeah, as of today (and probably for the foreseeable future) you can't use Kite while you're not connected to the internet. But honestly most programmers I speak to already rely a _lot_ on looking up material online while coding. Kite won't break your dev environment if you're disconnected, it just won't add anything.

Really, absurdly, ridiculously close. Like so close we almost delayed launch so that we could get it in.

(Copied from above.) Totally 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: kite.com/security. 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.

One of the big things we've worked on over the past few months is giving users fine grained control of which files are indexed by kite:

- Kite only indexes directories that you have explicitly enabled

- You can create a .kiteignore file (same semantics as .gitignore) to exclude specific files / patterns.

Sorry about this - it's embarrassing. We've been snowed under getting Kite ready for launch and didn't want to touch the update mechanism right before launch. We _will_ get this fixed ASAP.

In the mean time, check out http://help.kite.com/article/6-how-do-i-uninstall-kite

One of the big things we've worked on over the past few months is giving users fine grained control of which files are indexed by kite:

- Kite only indexes directories that you have explicitly enabled

- You can create a .kiteignore file (same semantics as .gitignore) to exclude specific files / patterns.

Totally 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: kite.com/security. 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.

Great to hear - we'll be there soon :)

Thanks - we're investigating. Seems to be working in most places but there may be an edge node out of line.

Author here. Yeah using servo might be workable because you could test all your HTML ahead of time and work around any problems (unlike the any-browser web workflow). Still I agree re stable release.

Author here. I would expect binary sizes to end up similar to Electron since they will be dominated by libchromiumcontent, unfortunately.

Author here. I have been thinking about writing a react-like component system for Go, that outputs HTML. The major down side is that then you can't re-use much between your web-based app and your desktop app (which I think is a common pattern now).

Author here. Yes this is a significant price to pay, but being able to test once and be sure that your users' experience will match your testing is worth a lot. It should be possible to have an updater that avoids downloading the main chromium dylib on most updates.

This is actually not based on CEF, btw, but on libchromiumcontent (the Electron alternative to CEF).

Yes but how much CPU and memory are you willing to spare? Parsing is quite CPU-intensive, hence the CPU drag you often see when IDEs start indexing, and type inference involves a lot of unpredictable lookups all over the index, so much of it needs to be in memory to get reasonable performance (yes this is still true if we're talking SSD).

To see why: when you type "x.foo()" we need run type inference on the complete data flow chain that produced the value "x", so that we know which particular "foo" you're using. Throughout this analysis we may also need to know a lot about the python libraries you're using, since you may be passing values into and out of arbitrary third party libraries. If each of the steps in this chain triggered an SSD read then you'd often have a multi-second lag between hitting a key and seeing the result.

Actually kite does not index any directories that you haven't explicitly enabled. So it's really easy to enable it for some but not all of your codebases.

The main difference versus IDEs is that everything we show is informed by all the public code we've collected from the web. So e.g. there are a ton of arguments to matplotlib.plot and IDEs can show you them all ranked alphabetically, whereas we can show you common patterns of how people actually use matplotlib.plot in practice, which is often far more useful. (We'll show you the docs, too.)

Another example is if you type "load('abc.json')" without having imported json: there are hundreds of python packages that define a function called "load", but "json" and "simplejson" are by _far_ the most widely used, so we can suggest that you "from json import load". That's something you can't do unless you have a good model of a lot of real-world code.

No! If you can't see it (as visible chars) on your terminal then Kite is not seeing it.

1. Yeah, I agree. It's hard, and it's something we continue to iterate on. How would you feel about a global keyboard shortcut that would show/hide the overlay that was a separate application?

2. I love Rust. We will get to it even though it's (sadly) not at the top of our list right now.

Yeah this is something we're still iterating on. Though it wasn't in the demo video, there is actually a global keyboard shortcut to show/hide the sidebar without defocussing your editor. We're going to be experimenting more.

Absolutely. We're going to be working on this for many years, and this is the kind of thing we're aiming at.

Agreed.

Yeah, this is something we should have put in the privacy doc. We're talking about it now. Definitely want to think properly on this stuff before posting something publicly (as with anything privacy-related) but we'll have an update.

Sorry if there was any confusion, but just FYI we're sending out the first invites today, so we're definitely "in motion".

Thanks! FYI: if you sign up at kite.com then you'll get to enter the language you use, so we can get in touch when we get to swift.

It's something we've thought a lot about. For anybody interested in this, shoot us a message at onprem@kite.com