Hacker News new | past | comments | ask | show | jobs | submit login

The main way SQLite is used around the world is as a library component of a larger application. The main way people use VS code is through the proprietarized official build that uses the official EULA.

Also, lots of people seem to value the proprietary extensions a lot more than people value the encryption extension of SQLite.




>The main way people use VS code is through the proprietarized official build that uses the official EULA

The blog author complained about "Live Share" as one example. As far as I can tell, "Live Share" is not in the builds one downloads from Microsoft's "Visual Studio Code" website: https://code.visualstudio.com/download

The Live Share feature is downloaded from a separate web page: https://marketplace.visualstudio.com/items?itemName=MS-vsliv...

This separation seems similar to SQLite Encryption Extension. Can someone explain how the situations are not analogous?

The github page for "Visual Studio Code" prominently displays "Open Source" in its title: https://github.com/microsoft/vscode

I'm willing to be convinced that it's a marketing deception and "open source" should be removed but so far, I haven't seen any precedent from other hybrid open/closed source projects justifying that.


> Can someone explain how the situations are not analogous?

The difference is that typical usage of SQLite is co-located with an application, such that you don't need encryption, and it doesn't market itself as a great database to stand up on a far-away server.

VSCode is marketing these extensions with the core product, as features thereof. They seem to be much closer to critical, core functionality. I think that they are functionally similar situations, except that nobody uses/cares-about that SQLite extension.

Microsoft is also marketing as if VS Code is open source. One claim or the other is fine, but the combination is deceptive. There are many closed-source components which are part of VS Code, if indirectly.


Hmm. Nobody I know that uses VSCode uses either Remote or LiveShare. They don't seem critical or core to me.


I've been using VS Code since day one, and I have zero interest in Remote or LiveShare. I can definitely see how they'd be useful in certain environments, but they just have no use to me.


Not that they are critical or core, but that they are, in the words of the original author, "the best parts of VScode." All the core and critical features of VScode exist in every other editor. LiveShare and Remote are, as far as I and the author can tell, not replicated by any other editor, and are therefore (subjectively) the "best parts". Whether or not you know anyone who uses the features is irrelevant.


The person I was replying to used the words "critical" and "core".

As to best (admittedly subjective) if they are so good I'd think that one of the 100s of devs I know depend on them.

The only close one was Remote - which other editors do too - When I showed that remote drops code to the far end machine we determined that to be too risky - and went back to sshfs.

Also, if those extension are so "best" why hasn't a replica been created? Or why didn't any other editor have them? It might be those extension are not so compelling.

Also, my previous favorite editor (jEdit) had remote features back in like 2003 - maybe earlier.


I don't agree with the word choice of the parent, but I think the argument stands if you replace "critical" and "core" with "best". That's why I chose to re-reference the original article.

I'm curious if you've used the live share features personally, and if you have if you've found value in them. I suspect many devs do not like collaborative programming in general, and so may never use them or like them if they have. As someone who thoroughly enjoys collaborative programming, I can tell you that these features are extremely compelling. It's way easier to tell your designer friend to boot up VScode and click on a link to your live app running locally than almost any other solution I've found. It also makes pair programming extremely easy.

I used to use vim and now emacs for everything. I've also used JetBrains products for years. The only reason I ever boot up VScode is for those features. You just can't replicate the experience in any other editor as easily. Every other feature of VScode I've found a similar or better solution in every other editor. I'd be interested to hear any other feature of VScode that you think is as compelling, without parallel in any other editor. I suspect there are few/none.


I love pair programming. I teach loads of juniors, that's how I know so many devs (that and hiring/recruiting).

So, the features of LiveShare I found are better handled with external tools. But that is mostly because I don't want anyone to become to dependent on one tool. How can I LiveShare between emacs and Sublime? WebRTC screenshare+A/V works a treat, across editors and systems.

I don't find VSCode, or it's extension super compelling. But it is very nice.

I think the feature I like the best, built in, is that debugger - that's easier/smoother than Atom, or jEdit or any others that I've used in the last 20 years. It's like what was available in Visual Studio 6 (c1999).


I doubt the author would make the same complaint if Microsoft wrote similar proprietary extensions for Emacs or Vim or Atom.

I also doubt they would make the same complaint if JetBrains or someone else wrote the same proprietary extension for VS Code.

Neither the first case nor the second would make any of those editors any less open source.


If Microsoft wrote a proprietary extension to emacs that was so compelling many would consider it to be the "best" feature, I think devs would complain. Emacs is way more FOSS than VScode claims to be, so that would be an even worse affront to the philosophy of the editor and community. Maybe you're right about the JetBrains products, but to my knowledge they don't market themselves as open-source to the extent that VScode does.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: