3 ms·
> Why put your time making plugins for VS Code when rug can be pulled from under any time? Because VSCode is a huge step forward for the vast majority of peopl
by bsder 4y ago
> Why put your time making plugins for VS Code when rug can be pulled from under any time?
Because VSCode is a huge step forward for the vast majority of people.
For example, it took the might of Microsoft to force everybody onto a Language Server Protocol which is how things should have been done everywhere but nobody wanted to work together to implement it until they were forced to by VSCode eating their market share.
As a further example, VSCode is sweeping aside a whole bunch of absolutely garbage embedded programming environments, and I assure you nobody is crying any tears for them.
Furthermore, if you make your own plugin and distribute it, Microsoft can't pull the rug out from under your plugin. The core of VSCode is open source.
Unfortunately, the most popular plugins are proprietary and Microsoft can and will rip the rug out from under people at some point.
However, the problem is that nobody is throwing the resources behind the open source plugins that Microsoft is throwing behind the proprietary ones. While I find the current situation distasteful, I also see it as "Pony money up or shut the hell up."
Sadly, the world of open source seems to be populated by a bunch of cheapass whiners. So, yeah, Microsoft gonna pwn.
- delta_p_delta_x 4y ago> As a further example, VSCode is sweeping aside a whole bunch of absolutely garbage embedded programming environments, and I assure you nobody is crying any tears for them. Quick point about embedded: in my short summer internship where I was working on some STM32 hardware, I was quickly exposed to the plethora of semi-proprietary embedded IDEs which were themselves based on FOSS IDEs and editors (STM32CubeIDE, MBED Studio, etc). Why do these even exist? It boggles the mind. These companies (NXP, STM, Infineon, TI, Nordic, MBED, etc) spend money on maintaining all this software and paying their own developers/contracting this IDE development work out. In the end, they're just glorified Makefile + C/C++ linters and editors. On the other hand, I had a particularly pleasant time writing embedded and remote C++ with CLion (it's still proprietary, but it's really good). I was writing a client C++ application running on the Raspberry Pi (cross-compiled, and remotely debugged) to communicate with an STM32 (also cross-compiled, and debugged with a probe). The debugging experience was glorious. One breakpoint in the client triggered another in the STM32, and everything was just completely seamless.
- bsder 4y ago> Why do these even exist? Because there existed a time before ARM, 32-bit processors, and gcc made embedded a monoculture like x86. Because there existed a time before IDEs converged via Language Server Protocol. This was predictable back when VSCode first came out. Microsoft was pouring more development resource into VSCode that many of those semiconductor companies entire revenue. Either you got on the VSCode train or you were going to get swept aside. The fact that everybody is whining about proprietary Microsoft remote development plugins while emacs tramp lsp-mode remains broken for an enormous number of cases for years says it all (this is finally what pried emacs out from under my fingers as I got tired of debugging it).