Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: TabNine, an autocompleter for all languages

tabnine.com

Post reply on HN
Print view View original

101–110 of 193 posts

Re: Show HN: TabNine, an autocompleter for all languages

#101

Post by danShumway »

setr wrote: post #78
danShumway wrote: post #61

> TabNine builds an index of your project, reading your .gitignore so that only source files are included. Heads up, it's not necessarily uncommon for JS developers to include node_modules in their git repos. If you're developing something like an Electron project or a website instead of a library, it's even sometimes advised to do so -- there's a line of thought that your static dependencies should be tracked as par…

Does npm not have version pinning? Why would you want to operate as if you didn't have a package manager, as your default behavior?

Depends on if you want to bother setting up Artifactory. The problem with having your dependencies outside of your project directory is you're now relying on a network request and a build step to get your stuff up and running.

It's obviously not right for every project, I wouldn't classify it as default behavior or even a standard behavior. But if you're already using Vagrant/Docker to standardize environments across your entire stack, there's an argument to be made that there's really no need to not to have your dependencies precompiled and local to the project.

If you can get rid of complexity, it's worth considering whether or not doing so might be a good idea. Across standardized environments, fetching dependencies is extra complexity.

Re: Show HN: TabNine, an autocompleter for all languages

#103

Post by heartbreak »

achamayou wrote: post #53
gbear605 wrote: post #49

Earlier quoted context omitted.

Some code is a lot more valuable than other code. For example, token files for connecting to remote servers.

There is no good reason for authentication secrets to be in your source tree though. I’m not suggesting this is perfect in any case, but it would at least place an upper bound on whatever amount of IP leakage you think might happen.

But do you ever edit your authentication secrets in your text editor? I edit my .env file in vim all the time.

Re: Show HN: TabNine, an autocompleter for all languages

#104

Post by fiatjaf »

krat0sprakhar wrote: post #16

Quoting the author from r/rust[0] > Its paid features are always enabled when completing Rust code, in acknowledgment of the fact that TabNine could not exist without the Rust ecosystem. Thanks for this, Jacob! [0] - https://www.reddit.com/r/rust/comments/9uhc1x/tabnine_an_aut...

That's odd, because it could indeed exist without the Rust ecosystem. The author just opted to write it in Rust.

Re: Show HN: TabNine, an autocompleter for all languages

#105

Post by JimDabell »

itdaniher wrote: post #28
jacob-jackson wrote: post #18

Earlier quoted context omitted.

Your concerns are understandable. It is about as risky as installing an editor plugin which updates automatically. The private keys used to sign releases are kept offline and would not be available to an attacker even if they compromised my online accounts. Finally, TabNine will work correctly if you deny it network access (say, by blacklisting update.tabnine.com).

...as risky as installing a proprietary editor plugin which updates automatically, yes. Also, AFAIK most understandings of MIT, BSD, and Apache 2.0 licenses require you to acknowledge the copyright holders of the source code you compile into your binary, even if the licenses permit binary distribution. I can't find your "Copyright (c) 2018 Tokio Contributors" or "Copyright (c) 2014 The Rust Project Developers" that I…

> ...as risky as installing a proprietary editor plugin which updates automatically, yes.

Can't you make the same complaint about any auto-update functionality in any software? Even if it's BSD licensed, you're still counting on whomever has authority to push an update to not push malicious code.

This doesn't seem to have anything to do with the fact that his code is proprietary nor his monetisation strategy, so why are you singling him out for those?

Re: Show HN: TabNine, an autocompleter for all languages

#106

Post by tzs »

kasbah wrote: post #86

Looks neat, will give it a go. I think you may be in violation of the GPL for your vim plugin since you are creating a combined work but are not releasing the TabNine source code under GPLv3. https://github.com/zxqfl/tabnine-vim/blob/master/COPYING.txt

It looks like it is probably OK. The vim plugin it is based on seems to have already been designed to run using a client/server architecture. The plugin is the client, and it gets its completions from a server.

He just changed it so that it uses TabNine as that server.

Re: Show HN: TabNine, an autocompleter for all languages

#107

Post by danShumway »

pitaj wrote: post #92
danShumway wrote: post #61

> TabNine builds an index of your project, reading your .gitignore so that only source files are included. Heads up, it's not necessarily uncommon for JS developers to include node_modules in their git repos. If you're developing something like an Electron project or a website instead of a library, it's even sometimes advised to do so -- there's a line of thought that your static dependencies should be tracked as par…

> it's not necessarily uncommon for JS developers to include node_modules in their git repos It's highly uncommon, and I've never seen an active, maintained, or popular project with it.

It's become less popular with the introduction first of ``shrinkwrap`` and then ``package-lock.js``. At one point in time, it was recommended behavior in the official NPM documentation for site deployments, because there wasn't a way to checksum dependencies.

They've since switched to recommending private repositories like Artifactory instead, which to be fair is usually better for very large organizations nowadays. But that wasn't always the case, and even as recent as 2013, it was the flat-out prevailing advice from package managers like Bower, and there are organizations who are still using and maintaining codebases that were set up in 2013.

You won't see a lot of projects on Github that rely on it, because:

A) Usually Open Source projects are designed to be built on multiple environments/OSes.

B) The majority of Open Source Javascript projects are designed to be installed via NPM anyway, and of course you wouldn't include dependencies for something like that.

However, you want to be careful not to make the mistake of assuming that every project has the same concerns as a standard Open Source project. Especially if an Org is going all in on standardizing dev environments through Vagrant or Docker, the question becomes, "why would you want an extra checkout/build step on top of that?"

Re: Show HN: TabNine, an autocompleter for all languages

#108

Post by warent »

fiatjaf wrote: post #104
krat0sprakhar wrote: post #16

Quoting the author from r/rust[0] > Its paid features are always enabled when completing Rust code, in acknowledgment of the fact that TabNine could not exist without the Rust ecosystem. Thanks for this, Jacob! [0] - https://www.reddit.com/r/rust/comments/9uhc1x/tabnine_an_aut...

That's odd, because it could indeed exist without the Rust ecosystem. The author just opted to write it in Rust.

Theoretically we don't even need programming languages or compilers at all. REAL programmers used a magnetized needle and a steady hand. [1]

Following your logic, nobody should show appreciation for anything.

[1] https://xkcd.com/378/

Re: Show HN: TabNine, an autocompleter for all languages

#109

Post by phiresky »

Nice. I had the same idea a while ago [1], but I didn't make it very far. Good to see that the concept of applying ML to intellisense can actually be useful.

[1]: https://github.com/phiresky/deep-intellisense Video https://www.reddit.com/r/programmerhumor/comments/8xrwr5/_/

Re: Show HN: TabNine, an autocompleter for all languages

#110

Post by nojvek »

pitaj wrote: post #92
danShumway wrote: post #61

> TabNine builds an index of your project, reading your .gitignore so that only source files are included. Heads up, it's not necessarily uncommon for JS developers to include node_modules in their git repos. If you're developing something like an Electron project or a website instead of a library, it's even sometimes advised to do so -- there's a line of thought that your static dependencies should be tracked as par…

> it's not necessarily uncommon for JS developers to include node_modules in their git repos It's highly uncommon, and I've never seen an active, maintained, or popular project with it.

to handle a static state of dependencies, usually a package-lock or a yarn.lock file is committed to the repo. That is the usual way to freeze the dependency tree.
Post reply on HN