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

Visual Studio Code is designed to fracture

ghuntley.com

Post reply on HN
Print view View original

51–60 of 149 posts

Re: Visual Studio Code is designed to fracture

#51

Post by brundolf »

keithnz wrote: post #34

Personally, I wouldn't actually care if Visual Studio Code was completely proprietary with zero open source element. I think the imagined consequences tend to mostly be not that significant for the vast majority of people, at most it would be a blip in the timeline as people switch to something else. The actual consequence (as implied by this article) seems to be people who build their business around these tools, th…

> The actual consequence (as implied by this article) seems to be people who build their business around these tools

But there aren't really even consequences for those. The core editor really is free to use however you want; you can use the auxiliary bits which are proprietary, or you can not use them and fill the gaps yourself. That's up to you.

Re: Visual Studio Code is designed to fracture

#52

Post by nindalf »

Good article. The author makes a compelling case about how Microsoft’s strategy isn’t on the up and up. I was never convinced that telemetry was inherently evil, but I do see the downsides of non-OSS language servers.

I have only one request of the author and others - please stop citing TIOBE (https://blog.nindalf.com/posts/stop-citing-tiobe/)

Re: Visual Studio Code is designed to fracture

#53

Post by zozbot234 »

isodev wrote: post #48
keithnz wrote: post #34

Personally, I wouldn't actually care if Visual Studio Code was completely proprietary with zero open source element. I think the imagined consequences tend to mostly be not that significant for the vast majority of people, at most it would be a blip in the timeline as people switch to something else. The actual consequence (as implied by this article) seems to be people who build their business around these tools, th…

The consequences for the majority are such that, over time, leading language ecosystems become tied to Microsoft services. One example in the article is the availability of alternative editors and IDEs decreasing over time in favor of extensions to VSCode. Essentially, we are driving towards a monoculture - either you are using VSCode and adjacent services, or you choose an alternative, pay the price of compatibility…

> leading language ecosystems become tied to Microsoft services

until a free alternative is developed. Making a freely-licensed language plugin is not inherently hard, it's just a lot of work. You're paying for convenience.

Re: Visual Studio Code is designed to fracture

#54

Post by shbooms »

Holy hell, this blog is virtually unreadable. Article content aside, the fact that after pretty much every single paragraph there's 1-2 giant links to some other article and/or an ad is just infurianting and makes it impossible to focus. I stopped reading after the first few and will be adding this site to my blocklist.

Re: Visual Studio Code is designed to fracture

#55

Post by slimsag »

skybrian wrote: post #19

I remember when the FSF had dire warnings about using the Sun JDK. I ignored it and kept on using Java, and nothing bad happened. The JDK was eventually GPLed, and by then I decided I didn't like Java anymore and moved on to better languages anyway. I feel kind of the same about VS Code. Binary product? Telemetry? Centralized marketplace? Some plugins are closed source? Eh, whatever. That stuff doesn't get in my way…

I wonder did the drive behind people creating open source JDKs have nothing to do with Sun open sourcing theirs? I wonder in an alternative world where Sun locked down Java as hard as possible and sued anyone and everyone, would they not have been bought by Oracle?

Are we sure that an editor will be able to displace VS Code in the future, if it's given away for free and so feature-packed? Browsers are another example of this. Or would the VS Code successor look like an Apple/Google/Amazon fork of VS Code?

Re: Visual Studio Code is designed to fracture

#56

Post by systemvoltage »

d0mine wrote: post #2

"The move affects millions of developers, as the Python extension is by far the most popular tool in the VS Code Marketplace" One of the reasons to use Emacs is to avoid asking Microsoft for permission to code.

The more diversity of tools programmers use, the merrier. We can't all pile up on one Big Tech™ thing and then no one dares to innovate or build another tool. I use vim and sublime text.

Similarly, I'd like to see more hardware besides every dev studio using Macbooks. Close to 100% marketshare of macbooks, if that happens, would be terrifying.

Microsoft, Apple are awesome. Just that they're now the size of nation states.

Re: Visual Studio Code is designed to fracture

#57

Post by mkl95 »

nine_k wrote: post #45
mkl95 wrote: post #20

I understand Visual Studio Code as a sophisticated Language Server Protocol frontend, and it generally does a good job at that. The IDE of the future will have Jetbrains grade UX with a heavy emphasis on LSP interfaces that "just work", rather than requiring some investigation about what setting needs to be set to which value and why basic stuff breaks mysteriously.

Interestingly, JetBrains offer Community Edition IDEs with the same extension interface as the paid versions. You could (and likely already can) support LSP integration through that. (What JetBrains sell is the depth of knowledge of a language and its ecosystem, advanced and specific code manipulation tools, and general polish and attention to detail. This is not impossible but pretty hard to reproduce in an open-sou…

JetBrains Fleet (https://www.jetbrains.com/fleet/) may already be doing something like this

> Fleet provides a polyglot experience, offering smart support for many languages and technologies out of the box, with support for even more planned via dedicated plugins. With the help of LSPs you will also be able to use other language services in Fleet.

> Fleet is designed to automatically detect your project configuration from the source code, maximizing the value you get from its smart code-processing engine while minimizing the need to configure the project in the IDE.

Re: Visual Studio Code is designed to fracture

#58

Post by suction »

georgia_peach wrote: post #24
TobyTheDog123 wrote: post #18

Earlier quoted context omitted.

Shift + Shift + Command + ESC + Shift + 1 + ~ + Shift + Esc + CTRL + Command + Shift + F1 + \x00 + F3 + ~ Phew! Finally back to my terminal

M-x, C-x, M-Shift-x is emacs, not vim. It's :q in vim. and to suction : because vi pre-dated those paradigms

No post body was provided.

Re: Visual Studio Code is designed to fracture

#59

Post by input_sh »

forgotmypw17 wrote: post #6

I had to use VS Code it briefly for a class, and was kind of shocked by the telemetry stuff, and that it's just ignore-accepted by both the students and the instructors. But what turned me off more was this janky feeling around the whole application, something I don't remember experiencing in many other Microsoft tools, such as VB. It feels like it was designed from the code up rather than from the interface down, an…

FYI you can get around HSTS errors on Chromium-based browsers by typing thisisunsafe.

Source: https://chromium.googlesource.com/chromium/src/+/d8fc089b62c...

Re: Visual Studio Code is designed to fracture

#60

Post by delta_p_delta_x »

bsder wrote: post #31
infinityplus1 wrote: post #3

This is what happens when you build software on another company's platform. Why put your time making plugins for VS Code when rug can be pulled from under any time?

> 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 sha…

> 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.

Post reply on HN