Don't understand why Microsoft is being accused of EEE, when Cursor is the one extending the functionality to VS Code. Can't you just say "Cursor good, Microsoft bad" without the straw grasping?
Using the C# debugger is also restricted to Visual Studio & VScode.
Microsoft loves open source, and windows is the most open operating system (look it up).
It’s totally not embrace, extend, extinguish in any disguise.
Coopetition exists (I’d point to the CNCF), but corporations do that really, really, begrudgingly only just due to the sheer complexity.
While I do not suspect that the somewhat benevolent notions will wane in the near future (the data is valuable enough, and you cannot afford to lose to another player), I sincerely enjoy just opting out because I like doing that.
Except, for example, VSCodium does not use vsdbg. It uses open-source NetCoreDbg maintained by Samsung and the fork of the extension, which itself is distributed under MIT and not subject to what article discusses.
But, you know, spreading FUD about .NET is way more important, is it not?
So what is supposed to be FUD about the usage restrictions for the kinda defunct csharp extension since MS took over omnisharp and the debugger being locked?
Because there are no restrictions on these extensions and they are open and MIT licensed (and the language server is part of the .NET SDK anyway) with the sole exception of the debugger which is a visual studio debugger made into standalone component. And the debugger case is non-issue since outside of VSC it is simply replaced by NetCoreDbg.
But it does not seem you care about any of this, it’s more important to post something negative.
Replies like these tend to indicate lack of skill and are a sign that the individual cannot be trusted in a professional setting to make impartial decisions.
Not really a surprise. The TOS for the extension marketplace has been clear that it's only to be used for VS Code, that's why VSCodium doesn't use it. Cursor devs undoubtedly knew better, but kept breaking TOS and licenses, MS just chose a strategic moment to enforce the rules already in place.
Cursor not being an extension from the start seemed odd to me, and they wouldn't be in this rough spot if they had done that.
While also the TOS of their extensions like C/C++ also prohibit their usage with forks. It is not about using marketplace endpoint, it is about using the extension itself even if the user installed the vsix manually. At least this is what this submission about.
There's plenty of non-MS alternatives to the official MS extensions even on VSCode, and those can also be distributed outside the 'marketplace'.
Specifically the MS C/C++ extension isn't all that great either, it isn't developed in the open, full of bugs, and those take forever to be fixed.
(e.g. for a Microsoft product, using VSCode is as low-risk as it gets when it comes to vendor-lockin, "just" don't be dependent on the closed-source VSCode extensions created by Microsoft)
I would recommend getting started with lazyvim (lazyvim.org). Once you're comfortable with the editor, you can change the config to kickstart.nvim and start customizing it to your liking. That's what I did and I have no regrets. LazyVim allowed me to switch without sacrificing productivity. I was on it for a year before I decided to make my own config
Don’t know about you, but personally I want the extensions I create to be available widely. The fact that vs code market place is used as an easy place for me to distribute it only to limit the reach based on the business needs of Microsoft sure does feel like being embraced extended in the attempt of extinguishing usecases that I do in fact support.
Can’t fault cursor for letting people install extensions when most of those, if not all of those, developers want their extensions on cursor.
This is about closed-source extensions created by Microsoft, and those always had strings attached which Cursor apparently ignored.
I would rather ask Cursor why they decided to fork VSCode when they could simply have written yet another VSCode extension to provide the same functionality. Seems shady AF tbh.
Doesn’t Microsoft handicap extensions by not giving them the full access that co-pilot gets? You’d be crazy to compete when the other side literally owns the platform.
They couldn't have done and it gets tiresome to repeat the technical limitations on extensions for vscode again and again (which don't apply to Microsoft owned extensions like Github Copilot) when you can google it yourself.
No confirmation from MS, but as usual conspiracy theorists are confident in the final conclusion.
You'd think if the release of copilot's Agent mode is what prompted this move, they'd be doing it in those languages more popular among vibe-coders first wouldn't you?
It’s totally not embrace, extend, extinguish in any disguise.
Coopetition exists (I’d point to the CNCF), but corporations do that really, really, begrudgingly only just due to the sheer complexity.
While I do not suspect that the somewhat benevolent notions will wane in the near future (the data is valuable enough, and you cannot afford to lose to another player), I sincerely enjoy just opting out because I like doing that.
Microsoft loves exploiting open source.
But, you know, spreading FUD about .NET is way more important, is it not?
Those are facts, why call it FUD?
But it does not seem you care about any of this, it’s more important to post something negative.
Replies like these tend to indicate lack of skill and are a sign that the individual cannot be trusted in a professional setting to make impartial decisions.
I won’t stoop to your level of claims, but maybe take your own criticism to heart :D
Cursor not being an extension from the start seemed odd to me, and they wouldn't be in this rough spot if they had done that.
As much as I like vscode it’s making me a little uncomfortable being reliant on it
Specifically the MS C/C++ extension isn't all that great either, it isn't developed in the open, full of bugs, and those take forever to be fixed.
(e.g. for a Microsoft product, using VSCode is as low-risk as it gets when it comes to vendor-lockin, "just" don't be dependent on the closed-source VSCode extensions created by Microsoft)
That part doesn't worry me. I am concerned about neovim not doing well in a copilot centric future though.
[0]https://github.com/yetone/avante.nvim
I was able to make VSCode behave like EMacs with vibe coding.
Neovim with Lazy is really easy to vibe code too.
Can’t fault cursor for letting people install extensions when most of those, if not all of those, developers want their extensions on cursor.
I would rather ask Cursor why they decided to fork VSCode when they could simply have written yet another VSCode extension to provide the same functionality. Seems shady AF tbh.
You'd think if the release of copilot's Agent mode is what prompted this move, they'd be doing it in those languages more popular among vibe-coders first wouldn't you?