For me the advantage of VSCode is in its approach and how it has differed from other products:
- VSCode Remoting is really useful. It doesn’t suffer as much from latency as SSH or display forwarding, and lets you use some local configuration when remoting. Neovim will soon have a feature like this.
- Language servers for code intelligence has greatly improved editor support for languages. Up until the introduction and adoption of LSP, which was practically an invention of VSCode, language support was significantly more hit-or-miss with most editors. Basically only IntelliJ IDEA could do similar code intelligence across many languages. Because of LSP though, more editors and more languages can participate in inline documentation, go to symbol, errors as you type, debugging, etc. for example, many people now use language servers with Vim, and you can see useful integrations for languages like Terraform/Hashicorp HCL.
- The extensions ecosystem: it isn’t necessarily the greatest ever, but it is very solid.
- Compared to many IDEs, it remains lightweight and fast to boot. Though I’m not complaining, (regular) Visual Studio and IntelliJ are too useful to ignore in some cases.
- Unification: because it’s so versatile, across OSes, across runtimes, over remoting, over Code Spaces, you can buy into the ecosystem in your projects. You can tell Code Spaces what extensions to install and what commands to run, to try to build a nice environment. You can tell desktop VS Code what extensions are recommended, add workspace configuration to help improve the workflow. Users still can use other editors, and you can still include editor information for those editors too. But, for someone who just wants a good option to edit a specific project, pushing them towards VS Code is a really safe bet.
To be clear it has some issues too:
- There is no equally useable OSS version, as the Microsoft distribution has become more dependent on services and blobs.
- It’s not as quick and responsive as something like Sublime Text or vim.
… but honestly, I think it’s just great. If I was a new programmer again and I could jump right into projects and immediately begin working on them without having to figure out the rigmarole of version control, tool chains, build system and editor config, that would be amazing. For that reason I think Code Spaces and VSCode are net goods, though I think we ought not become too dependent on the specific solution. VSCode is never going to be the perfect editor for any specific use, but I believe overall it is usually a great editor.
I get worried that VS Code is too popular, and that some higher ups might be tempted to go for an EEE play.
The flipside is that MS pouring money into VS Code has tremendously benefited the entire code editor ecosystem, including (especially) FOSS editors that can reuse their language servers.
> This is why MIT isn't always the correct choice. GPL wouldn't hurt devs at all and would protect from this kind of garbage from MS.
But would it protect against Pylance existing, or would it just be more expensive to develop but still proprietary (and possibly not free-as-in-beer), or would it be Free?
There's only one of those three where devs (as opposed to Free Software ideologues) win, and one where both lose.
(And really, it would do none of those, since pyright is also owned by MS, so they could reuse it on any terms even if the owner [them] offered it to others only under GPL terms. All GPL would do is prevent someone else from competing with Pylance by taking pyright and building similar functionality on top, possibly with a still-Free license.)
If pyright were GPL'd then MS would own their own pieces, but the contributions would be owned by others and that would prevent the relicensing you're talking aobut.
MS could pay a dev team to write everything themselves, but it's a matter of cost. Given the choice between paying for a ground-up development for a tiny gain or using the open project, inertia would push toward the open project.
Finally, there's the question of trust.
Why does MS feel the need to lock these things down?
It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
> It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
There's never a question of Microsoft's goal. It is always to destroy your choice to use non-Microsoft products. They pour resources into a "free" product that I will admit is good. It has to be, to kill all competing products over many years. Then when there is no reasonable competing product, they switch it to a paid product.
I can remember when Windows 3.1 was released. I did development on it at Ford, to emulate a vector graphics terminal. I remember when Office was bundled with Windows for free; now it is 1/3 of their revenue. I have seen Microsoft repeat this game over and over. History truly does repeat itself.
> If pyright were GPL'd then MS would own their own pieces, but the contributions would be owned by others
So in your hypothetical, Microsoft not only uses the GPL instead of MIT outbound, but accepts contributions under the GPL instead of the CLA it uses for most MS open source project contributions, including pyright, inbound, etc.?
If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
> If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
How is that any less true when the outbound license is MIT, and, therefore, how is the fact that they get contributions with the CLA now not a firm disproof of that claim?
I wish this point was brought up more often. Like in the TiVo case when everyone lost their minds about ideology, meanwhile millions of people got to watch what they wanted on their schedule and with no ads.
This attitude of MIT being bad because it gives people freedom to do Bad Things™ really makes me question what open source is actually about (yes I know that it's complicated and means many things, that's not what I'm talking about here). It seems to me that some proponents of it really believe in it so they can tell other people what to do.
In this case both Pylance and Pyright are developed by Microsoft.
I suspect that open-sourcing in anything at all is essentially a long-term PR/marketing/recruiting investment, as well as as positioning Microsoft as the keepers and main developers of what has become an important standard.
That said, by "reuse" I mean that end-users are free to install the non-free binaries extracted from VS code, which interoperate with any text editor that implement a language client. They are all on NPM.
Can you point to how? Pretty much all of the functionality Microsoft has made that is proprietary they’ve packaged inside extensions. The app itself works fine without those extensions.
I read some of that issue but it seems to be about OpenVSX, and one of the solutions was to try switching to the official extension marketplace, probably against ToS. That seems to not be sabotage.
- VSCode Remoting is really useful. It doesn’t suffer as much from latency as SSH or display forwarding, and lets you use some local configuration when remoting. Neovim will soon have a feature like this.
- Language servers for code intelligence has greatly improved editor support for languages. Up until the introduction and adoption of LSP, which was practically an invention of VSCode, language support was significantly more hit-or-miss with most editors. Basically only IntelliJ IDEA could do similar code intelligence across many languages. Because of LSP though, more editors and more languages can participate in inline documentation, go to symbol, errors as you type, debugging, etc. for example, many people now use language servers with Vim, and you can see useful integrations for languages like Terraform/Hashicorp HCL.
- The extensions ecosystem: it isn’t necessarily the greatest ever, but it is very solid.
- Compared to many IDEs, it remains lightweight and fast to boot. Though I’m not complaining, (regular) Visual Studio and IntelliJ are too useful to ignore in some cases.
- Unification: because it’s so versatile, across OSes, across runtimes, over remoting, over Code Spaces, you can buy into the ecosystem in your projects. You can tell Code Spaces what extensions to install and what commands to run, to try to build a nice environment. You can tell desktop VS Code what extensions are recommended, add workspace configuration to help improve the workflow. Users still can use other editors, and you can still include editor information for those editors too. But, for someone who just wants a good option to edit a specific project, pushing them towards VS Code is a really safe bet.
To be clear it has some issues too:
- There is no equally useable OSS version, as the Microsoft distribution has become more dependent on services and blobs.
- It’s not as quick and responsive as something like Sublime Text or vim.
… but honestly, I think it’s just great. If I was a new programmer again and I could jump right into projects and immediately begin working on them without having to figure out the rigmarole of version control, tool chains, build system and editor config, that would be amazing. For that reason I think Code Spaces and VSCode are net goods, though I think we ought not become too dependent on the specific solution. VSCode is never going to be the perfect editor for any specific use, but I believe overall it is usually a great editor.