Live data from Hacker News

Microsoft subtracts C/C++ extension from VS Code forks

theregister.com

41–50 of 354 posts

Re: Microsoft subtracts C/C++ extension from VS Code forks

#41
post #15

Earlier quoted context omitted.

I spent 25 years using emacs before vscode (1997 to 2022-ish). I didn't go deep, I mostly just enjoyed the core parts of emacs + ccmode. I don't enjoy LISP but I still enjoy emacs, if that makes any sense. MS made some very real and very usable innovations. Emacs hackers/maintainers would be wise to copy them, like I'm sure Microsoft copied things from emacs. It's a bit like the UI aspect of the browser wars. Everyon…

What are the ways that VScode is better than Emacs?

I listed my favorites above.

Generalizing it: Having smart people who really understand UX helps a lot with minimizing those months of pain before the payoff.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#42
post #37

Shitty move (as expected from Microsoft) but I don't see the bigger issue. The beauty of open source is that you can always roll back to a version that did work. Of course continued developement and support from there on is your problem, but Microsoft never owed that to you anyways. Cursor, Codium and all the other VS Code forks have unlimited VC funding and are worth tens of billions of dollars combined. They can af…

The C/C++ extension isn't open source though, and that's where the "doesn't work on forks" DRM is implemented. At least the clangd extension is open source and is a viable alternative.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#43
At least I know one alternative that is on bar (even better according to some people) for the C++ MS extension. What I am worried more about is the Jupyter Notebook MS extensions. I cannot find a suitable alternative and sometimes I am not being able to use it on windsurf/VSCodium (manually installing vsix). I am surprised by that taking into consideration how Jupyter notebooks relevance in data science and ML.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#44

Do you guys ever feel tired of 'sounding the alarm'? I feel like I've been doing that for years on a wide range of topics, but every time it's like you're talking to cult members. How do you break through to people? People say things like "you're overthinking it", "that's never going to happen", "I don't care because I like using VSCode and not alternatives". Is it individualism? That they only consider their own nar…

I’ve just lost all hope and have rock bottom expectations. Probably not the healthiest coping mechanism.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#45
post #42
post #37

Shitty move (as expected from Microsoft) but I don't see the bigger issue. The beauty of open source is that you can always roll back to a version that did work. Of course continued developement and support from there on is your problem, but Microsoft never owed that to you anyways. Cursor, Codium and all the other VS Code forks have unlimited VC funding and are worth tens of billions of dollars combined. They can af…

The C/C++ extension isn't open source though, and that's where the "doesn't work on forks" DRM is implemented. At least the clangd extension is open source and is a viable alternative.

Well if it isn't open source then they should never have been using it in the first place.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#46

Do you guys ever feel tired of 'sounding the alarm'? I feel like I've been doing that for years on a wide range of topics, but every time it's like you're talking to cult members. How do you break through to people? People say things like "you're overthinking it", "that's never going to happen", "I don't care because I like using VSCode and not alternatives". Is it individualism? That they only consider their own nar…

And when it turns out you were right the whole time they will pretend no one saw it coming and blame you for the problem.

You just have to let go of things you have no real influence over.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#47

I love Cursor deeply but choosing to be a VSCode fork instead of a VSCode extension was a fatal choice. In the long term I think they either have to retool as an extension or they will go out of business. You can only publicly flout Microsoft's licenses for so long while making a competitor to one of their AAA products.

Eh, I mean it's a fork. They can keep updating their fork forever. Reality is they want complete control over the product, and VS Code doesn't expose everything in the extension API.

Sure, but they depend on a bunch of Microsoft proprietary extensions (that they can't fork) that ban usage in VSCode forks, and they knew this when they made the choice. This was an inevitable outcome from Microsoft's side. I'm sure they want to remain in business more than they want complete control over the product.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#48
post #4

And this is why I'm using Zed today. I'm deadly serious. I was a huge proponent of VSCode at first but I've soured on it, and now I don't want my workflow to depend on it in any way. Awesome software, but I don't trust the upstream org further than I must.

Still using VSCode, but you kind of know that's it's going to go sour eventually. It is Microsoft. :/ I figure e.g. emacs will always be there when that happens. All I need is a Github Copilot clone and a good code search feature. Oh and automatic reloads of open but unchanged buffers when switching between git branches. Oh and the ssh remote extension.

> All I need is a Github Copilot clone

I'm using https://github.com/copilot-emacs/copilot.el

> good code search feature.

project-find-regexp is a nice start.

> Oh and automatic reloads of open but unchanged buffers when switching between git branches.

(global-auto-revert-mode t)

> Oh and the ssh remote extension.

I haven't compared it to Tramp.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#49

Look, if you willingly have any piece of your stack relying on Microsoft you have to be ready for the rug pull. They WILL fuck you, it's guaranteed.

Not to quibble, but VSCode (and GitHub for that matter) are part of my tooling, not part of any of my stacks. To me the former is tolerable, the latter is not.

I've been shafted by Github under MS ownership in the past, after 7 years. I'm using a gitea instance ever since. The only thing Github is good for is visibility/discoverability. Do not trust Microsoft ever. They will fuck you.

Re: Microsoft subtracts C/C++ extension from VS Code forks

#50
post #4

And this is why I'm using Zed today. I'm deadly serious. I was a huge proponent of VSCode at first but I've soured on it, and now I don't want my workflow to depend on it in any way. Awesome software, but I don't trust the upstream org further than I must.

Still using VSCode, but you kind of know that's it's going to go sour eventually. It is Microsoft. :/ I figure e.g. emacs will always be there when that happens. All I need is a Github Copilot clone and a good code search feature. Oh and automatic reloads of open but unchanged buffers when switching between git branches. Oh and the ssh remote extension.

> All I need is a Github Copilot clone

or you could just use copilot through copilot.el

> and a good code search feature.

Like through helm or ivy?

> Oh and automatic reloads of open but unchanged buffers when switching between git branches.

My emacs does that, and I don't think I did anything special to get it.

> Oh and the ssh remote extension.

like tramp?

Post reply on HN